Welchen Cube MX und IDE für den H7

Harry L. schrieb:
> Version sollte 1.5.0 sein....für ein Betriebssystem deiner Wahl.
> CubeMX ist bereits enthalten.
>
> https://www.st.com/en/development-tools/stm32cubeide.html

Super Danke. Genial alles dabei. Und was fehlt wird direkt automatisch 
runtergeladen.

Hmm einzig etwas: Wie kann ich den ADC tripple interleaven? Anscheinend 
wird das beim H7 nicht mehr direkt unterstüzt (F4 giengs soweit ich mich 
erinnern kann einfach). Gibts da einen Workaround per Interrupt die 
conversationen zu starten und manuell zu interleaven (gegebenenfall 
unter Verwendung eines/mehreren internen OPAmps für die Bufferung(en))?

FPGA schrieb im Beitrag #6480704:
> Wie kann ich den ADC tripple interleaven?

Ich weiss zwar nicht was das genau bedeutet, aber im Datenblatt:

F7:
• 3×12-bit, 2.4 MSPS ADC: up to 24 channels
and 7.2 MSPS in triple interleaved mode

H7:
• 2×16-bit ADC, up to 3.6 MSPS in 16-bit: up to
18 channels and 7.2 MSPS in double-
interleaved mode
• 1 x 12-bit ADC, up to 5 MSPS in 12-bit, up to 12
channels

Kevin M. schrieb:
> Es gibt maximal 2 "tightly coupled" ADCs, ADC1 und ADC2. ADC3, sofern
> vorhanden, ist immer independent. Bei neueren wie dem G4 der 5 ADCs hat
> geht das auch mit 2 Kanälen aber pro Kanal dennoch nur zwei ADC. In dem
> Fall ADC1&2 sowie ADC2&4, ADC5 ist independent.

Schade...
Ein Workaround, dass diese extern (über den Opamp gebuffert) 
zusammengeschaltet werden, und durch Inkaufnahme einer erheblichen CPU 
Last die einzelnen ADCs per interrupt interleavet werden besteht nicht?
Falls doch evtl. auch die Möglichkeit durch eine geschickte 
Konfiguration der DMAs eine Art interleving über die DMA entsteht?

auf der 'nervigen' STM Website gibt es auch reichlich AppNotes, hast du 
da mal nachgesehen ob es etwas zum ADC der M7/H7 gibt?

FPGA schrieb im Beitrag #6480650:
> 2. 5 h sich über das bescheuerte HAL nerven

Dann benutze einfach kein HAL.

Irrer Iwan schrieb:
> Dann benutze einfach kein HAL.

Eine Zeit lang konnte die IDE nur Projekte mit HAL (bzw. LL Bibliothek) 
erzeugen, aber das haben sie inzwischen wieder geändert.

Stefan ⛄ F. schrieb:
> Eine Zeit lang konnte die IDE nur Projekte mit HAL (bzw. LL Bibliothek)
> erzeugen, aber das haben sie inzwischen wieder geändert.

Wie jetzt? Das ist doch alles nur C Code? Ich kann doch auch alles 
löschen und nur mi CMSIS programmieren? Wieso sollte mir die IDE das 
verbieten?

Irrer Iwan schrieb:
> Ich kann doch auch alles löschen und nur mi CMSIS programmieren?

Klar, den ganzen Rotz wieder weg löschen ging natürlich immer.

Johannes S. schrieb:
> auf der 'nervigen' STM Website gibt es auch reichlich AppNotes, hast du
> da mal nachgesehen ob es etwas zum ADC der M7/H7 gibt?

Die ST Seite war diesmal nicht nerfig, und das appnote habe ich einfach 
gefunden :-).
Der Inhalt ist Nerfig: Anscheinend hat sich ST selbst ubertroffen und 
vergessen eine aktive S&H Schaltung einzubauen :-(. Der S&H C wird 
anscheinend rein passiv über den Pin geladen; dann beschreiben sie noch 
ausführlich wie dies die AD-Performance zerstört (insbesondere für die 
für hobbyisten relevanten TQFP)...

Irrer Iwan schrieb:
> FPGA schrieb im Beitrag #6480650:
>> 2. 5 h sich über das bescheuerte HAL nerven
>
> Dann benutze einfach kein HAL.

Ja genau dann 10h für Registergedöns verheizen....

Die Motivation den Cube einzusetzen ist, dass man keine Datenblätter, 
Appnotes etc lesen muss. Einfach Cube starten, alles hochschrauben bis 
der Cube reklamiert, dann den letzten Wert nehmen wo der Cube gerade 
noch nicht reklamiert hat, dann mit dem HAL zurechtkommen. Fertig. 
(Wesentlich effizienter als Datenblätter, ST-Webseite, Appnote etc...)

Anyway der ganze Ansatz geht natürlich mächtig schief wenn der 
Hersteller solch massive Böcke schiesst wie passiv S&H bei nem 16bit SAR 
ADC im MS/s Bereich.

Weiter kann ich im Cube den ADC clk auf 480MHZ stellen ohne das der Cube 
reklamiert?!? Dies ist ein bug oder? Im Datenblatt ist von 50MHz die 
rede...

FPGA schrieb im Beitrag #6481813:
> Ja genau dann 10h für Registergedöns verheizen....
>
> Die Motivation den Cube einzusetzen ist, dass man keine Datenblätter,
> Appnotes etc lesen muss. Einfach Cube starten, alles hochschrauben bis
> der Cube reklamiert, dann den letzten Wert nehmen wo der Cube gerade
> noch nicht reklamiert hat, dann mit dem HAL zurechtkommen. Fertig.
> (Wesentlich effizienter als Datenblätter, ST-Webseite, Appnote etc...)

Ich investiere lieber einmal 10h (realistisch natürlich deutlich 
weniger), um dann alles verstanden zu haben um dann effizient auf 
Registerebene programmieren zu können, als irgendeine magische Blackbox 
Software voll Bugs und Overhead zu benutzen.

Also wieder so ein Arduino Feeling? Ich brauche genau zwei Datenblätter: 
Das Reference Manual und das Datenblatt vom entsprechenden Controller.

Wer das nicht hinkriegt darf sich am Ende nicht wundern und darf sich 
auch nicht Profi nennen!

FPGA schrieb im Beitrag #6481813:
> Dies ist ein bug oder?

Wäre dir ohne HAL nicht passiert.

Irrer Iwan schrieb:
> realistisch natürlich deutlich
> weniger

Na dann bist du aber gut. Um all die Funktionen von H7 auf Registerlvl 
nutzen zu können, inkl. der etlichen DMA und Interrupts; und dabei noch 
alles zu verstehen... in weniger als 10h für dich als erfahrener STMer 
vieleicht. Ich als FPGAler werde da wohl Mühe haben.

Irrer Iwan schrieb:
> FPGA schrieb im Beitrag #6481813:
>> Dies ist ein bug oder?
>
> Wäre dir ohne HAL nicht passiert.

Na toll ST... Was ist nun die max ADC clk Einstellung beim H7? (Dann 
nutze ich einfech den 2. PLL um die freq zu machen...)

Nur damit es den ST Fans nicht in den falschen Hals kommt: Quartus II 
kann ebenfalls ordentlich nerfen, und ist hierbei vermutlich 
konkurenzfähig...

Beim H7 ist auch noch das Errata wichtig, da gibts zum Teil schon 
mehrere Revisionen und die sind auch im HAL berücksichtigt.

Kevin M. schrieb:
> FPGA schrieb im Beitrag #6481646:
>> Ein Workaround, dass diese extern (über den Opamp gebuffert)
>> zusammengeschaltet werden, und durch Inkaufnahme einer erheblichen CPU
>> Last die einzelnen ADCs per interrupt interleavet werden besteht nicht?
>
> Ohne Gewähr eventuell wenn du sie über einen Timer mit vershciednenen
> compare Werten triggerst. Wie präzise das funktiniert müsste man testen.

Danke, genau das war auch meine Idee; mit dem zusatz, dass dies durch 
geschikte konfiguration der DMAs nur initial so gestartet werden müsste 
und im folgenden so durchlaufen würde.
Nun leider scheint es so zu sein, dass ST vergessen hat eine angemessene 
S&H Schaltung zu bauen. Daher ist bei TQFP Gehäusen schon bei 1.9MS/s 
Schluss mit 16 bit. Auch wenn erst im Datenblatt angegeben ist, dass 
Dual interleved 7.2 MS/s möglich sind...
Also AD Teil beim H7 ist ein major FAIL. Hoffe ST überarbeitet dies zum 
"H8", dass zumindest 10MSPS mit 16 bit möglich sind....

FPGA schrieb im Beitrag #6480650:
> 2. 5 h sich über das bescheuerte HAL nerven

Im CubeMX kannst Du irgendwo in den Optionen den generierten Code von 
HAL auf LL umstellen. Mache ich immer so, dann ist der Spuk vorbei.

Martin schrieb:
> FPGA schrieb im Beitrag #6480650:
>> 2. 5 h sich über das bescheuerte HAL nerven
>
> Im CubeMX kannst Du irgendwo in den Optionen den generierten Code von
> HAL auf LL umstellen. Mache ich immer so, dann ist der Spuk vorbei.

Hmmm naja LL ist schon sehr registernahe. Also grundsätzlich ist die HAL 
idee genial, lediglich die ST Umsetzung ist, naja: Ziel verfehlt... Am 
liebsten wäre mir eine alternatives Templateprojekt mit einem guten HAL. 
Template wo alle clk auf max sind und alles aktiviert.
Dann könnte im Cube nur die Pinzuweisungen gemacht werden und lediglich 
die entsprechenden init funktionen aus dem cube in das template 
kopieren.

FPGA schrieb im Beitrag #6484018:
> lediglich die ST Umsetzung ist, naja: Ziel verfehlt

Ich denke darüber anders. ST bindet die Entwickler damit an sich, genau 
wie Microsoft es geschafft hat.

Das der HAL gar kein ernsthafter Hardware-Abstraktionslayer ist, 
brauchen wir nicht zu diskutieren. Ohne Cube MX wäre das Zeug schon 
längst wieder in der Versenkung verschwunden.

Andererseits könnte Cube MX durchaus auch Code ohne solche Bibliotheken 
erzeugen. Aber das will ST vermutlich nicht, weil dann würden sich die 
Programmierer mit Registersätzen beschäftigen, die sie bei anderen 
Mikrocontrollern wieder finden könnten.

Stefan ⛄ F. schrieb:
> Aber das will ST vermutlich nicht, weil dann würden sich die
> Programmierer mit Registersätzen beschäftigen, die sie bei anderen
> Mikrocontrollern wieder finden könnten.

Nun ich denke beriets darüber ST zu verlassen bevor ich richtig begonnen 
habe. Zwar ist es schön mit dem H7 16bit ADCs zu haben für 5-10USD, 
anyway S&H Fehler zerstört den Vorteil/Sinn komplett.
Dann die HAL Geschichte...
Wie siehts bei den anderen Herstellern aus? Renesas habe ich vor langem 
mal gutes gehört, NXP etc? Dies insbesondere in Bezug auf realle ADC 
Performance, und Bemutzerfreundlichkeite (HAL) etc...

Ben S. schrieb:
> Was interessieren mich da die ganzen Peripherien? Clock, GPIOs, DMA,
> Timer, U(S)ART, WWatchdog, ....

Nun bei jedem noch so kleinen Projekt muss man erst mal alle clk auf max 
setzen, damit man auch sicherstellt dass man dem Ding den Gang einlegt. 
GPIO werden sowiso immer gebraucht. USART, Timer etc. auch, ADC 
ebenfalls. DMAs werden bei einfachen projekten mit einer solchen CPU 
zwar nicht dringend benötigt, aber ja...
Also eigentlich könnte man bei einfachen Projekten fast alles mit einer 
ISR machen (USART über GPIO etc) und so die CPU last hochschrauben...

Ben S. schrieb:
> Vermutlich würde ich andererseits im Fall dass ich mich in FPGAs
> einarbeiten muss deutlich länger brauchen, da sehr wenig Erfahrung.

Ja ist so. Naja kommt draufan. Verilog/VHDL sind eigentlich nicht so 
schwierig (die Logik ist immer Statemaschine+Datenpfad und einfacher als 
man denkt), die sprachen sind jedoch aus den 80ern und etwas outdatet. 
Nerfig ist dass verfolgen der Signale über mehrere Dateien. Ich nutze 
notepad++ als einfachen editor. Sigasi ist eine professionellere 
Methode. Bezüglich UART etc. kann relativ einfach ein Softcore NIOS 
eingebaut werden. Der gratis NIOS hat jedoch nur 0.1 IPC und läuft auf 
100-200MHZ. Die Einbindung von GPIOs zur FPGA logik ist sehr einfach.
Was ich auf der Suche bin und noch keine befriedigende Lösung gefunden 
habe ist eine Moderne FPGA anbindung an einen PC (PCI-E, Ethernet oder 
so). Dieser Datentransfer ist eigentlich eine Basis worauf man aufbauen 
können sollte. Anyway diese Basis wird nicht vernünftig zur Verfügung 
gestellt.

Ben S. schrieb:
> Dort
> könnte ich natürlich auch zu 90% fertige IP Bausteine nutzen - das würde
> ich aber auch nicht wollen und von anfang verstehen was ich da mache und
> wie es funktioniert.

Dies funktioniert zu 90% nicht. Naja viel Papier, Chaos, und kein 
funktionierendes Demo... Zumindest bei Altera/Intel ist dies 
frustreirend

FPGA schrieb im Beitrag #6484534:
> Nun bei jedem noch so kleinen Projekt muss man erst mal alle clk auf max
> setzen,

Nö, dann kommt der Stromsparer der die PLL gar nicht aktivieren will. 
Und woher weiß die Universal Max Funktion ob du einen Quarz oder 
Oszillator benutzt? Und welche Frequenz der hat? Die ganzen 
Einstellungen sind so variabel das es kaum möglich oder sinnvoll ist. 
Bei einigen Quarzfrequenzen vertragen sich z.B. USB und max. Sysclock 
nicht. Und gerade der H7 hat mit mehreren PLLs und internen clocks doch 
unzählige Möglichkeiten. Selbst CubeMX rechnet sich doof wenn er 
versucht die PLL Einstellungen zu ermitteln.
Und selbst der LSE rennt nicht einfach los wenn man irgendeinen Quarz 
dranhängt, da musst du noch den drive load level richtig einstellen.

Habe nun den H7 am laufen. Debbuger funktioniert super. Core gem. cube 
auf 480mhz. Nur die performance ist nicht wie ich sie erwartet hätte:

for(i=0;i<480000000;i++); benötigt 14sec

folgend übersetzt:

119           for(i=0;i<480000000;i++);
08000602:   movs    r3, #0
08000604:   str     r3, [r7, #4]
08000606:   b.n     0x800060e <main+54>
08000608:   ldr     r3, [r7, #4]
0800060a:   adds    r3, #1
0800060c:   str     r3, [r7, #4]
0800060e:   ldr     r3, [r7, #4]
08000610:   ldr     r2, [pc, #12]   ; (0x8000620 <main+72>)
08000612:   cmp     r3, r2
08000614:   ble.n   0x8000608 <main+48>

wobei wie ersechtlich beim hochzählen 6 instruktionen pro Zählung.

Müsste daher mit 480MHZ und 2.76 IPC ca. 2.2 sec dauern. Woher kommt der 
enorme performance unterschied? Hat der H7 keinen Branchpredictor?

Jan K. schrieb:
> Wie hast du das denn gemessen?

Nun quick and dirty: nur ein breakpoint setzen und laufen lassen. Ist so 
auf die Sekunde genau...

Der Flash Speicher ist viel langsamer als 480 MHz, nämlich 70 MHz. Hast 
du den L1 Cache aktiviert?

Siehe Application Note AN4891 Kapitel 2.5.

Stefan ⛄ F. schrieb:
> Der Flash Speicher ist viel langsamer als 480 MHz, nämlich 70 MHz.
> Hast
> du den L1 Cache aktiviert?
>
> Siehe Application Note AN4891 Kapitel 2.5.


By default, the instruction cache and the data cache are both 
disabled.The Arm® CMSIS library provides two functions that enable data 
and instruction caches:•SCB_EnableICache() to enable the instruction 
cache•SCB_EnableDCache() to enable and invalidate the data cache

Toll genau das ist es, Danke. Nun dauerts ca. 6 sec. Also ca. 1 IPC.

Kann da noch etwas weiter konfiguriert werden. Z.b. dass sowohl I als 
auch D Cache beide auch mehrere Addressierkanäle nutzen um die hohen IPC 
Werte zu erreichen? Out of order ex aktivieren? Nutzung aller ALUs, 
Load/Store, Instruction decoders etc...?

FGPA schrieb:
> Kann da noch etwas weiter konfiguriert werden.

Lass mal das volatile vor der Variable i weg oder schalte die 
Optimierung ein. Dann geht es superschnell ;-)

FGPA schrieb:
> 0800060c:   str     r3, [r7, #4]
> 0800060e:   ldr     r3, [r7, #4]
> 08000610:   ldr     r2, [pc, #12]

Diese Befehle sollten bei einer realen Anwendung nur einmal ausgeführt 
werden. Eine leere Schleife ist keine gute Testroutine.

m.n. schrieb:
> FGPA schrieb:
>> Kann da noch etwas weiter konfiguriert werden.
>
> Lass mal das volatile vor der Variable i weg oder schalte die
> Optimierung ein. Dann geht es superschnell ;-)
>
> FGPA schrieb:
>> 0800060c:   str     r3, [r7, #4]
>> 0800060e:   ldr     r3, [r7, #4]
>> 08000610:   ldr     r2, [pc, #12]
>
> Diese Befehle sollten bei einer realen Anwendung nur einmal ausgeführt
> werden. Eine leere Schleife ist keine gute Testroutine.

Wo du recht hast hat du recht. Nun habe folgende Modifikation gemacht:

    for(i=0;i<480000000;i++){
      k=k*k;
      l++;
      m=m/2;
      n=n-1;
      o=k;
      p=22;
      r=44;
      s=k;
      t=k/2;
    }

122           for(i=0;i<480000000;i++){
080006ca:   movs    r3, #0
080006cc:   str     r3, [r7, #44]   ; 0x2c
080006ce:   b.n     0x8000714 <main+124>
123             k=k*k;
080006d0:   ldr     r3, [r7, #36]   ; 0x24
080006d2:   ldr     r2, [r7, #36]   ; 0x24
080006d4:   mul.w   r3, r2, r3
080006d8:   str     r3, [r7, #36]   ; 0x24
124             l++;
080006da:   ldr     r3, [r7, #32]
080006dc:   adds    r3, #1
080006de:   str     r3, [r7, #32]
125             m=m/2;
080006e0:   ldr     r3, [r7, #28]
080006e2:   cmp     r3, #0
080006e4:   bge.n   0x80006e8 <main+80>
080006e6:   adds    r3, #1
080006e8:   asrs    r3, r3, #1
080006ea:   str     r3, [r7, #28]
126             n=n-1;
080006ec:   ldr     r3, [r7, #24]
080006ee:   subs    r3, #1
080006f0:   str     r3, [r7, #24]
127             o=k;
080006f2:   ldr     r3, [r7, #36]   ; 0x24
080006f4:   str     r3, [r7, #20]
128             p=22;
080006f6:   movs    r3, #22
080006f8:   str     r3, [r7, #16]
129             r=44;
080006fa:   movs    r3, #44 ; 0x2c
080006fc:   str     r3, [r7, #12]
130             s=k;
080006fe:   ldr     r3, [r7, #36]   ; 0x24
08000700:   str     r3, [r7, #8]
131             t=k/2;
08000702:   ldr     r3, [r7, #36]   ; 0x24
08000704:   cmp     r3, #0
08000706:   bge.n   0x800070a <main+114>
08000708:   adds    r3, #1
0800070a:   asrs    r3, r3, #1
0800070c:   str     r3, [r7, #4]
122           for(i=0;i<480000000;i++){
0800070e:   ldr     r3, [r7, #44]   ; 0x2c
08000710:   adds    r3, #1
08000712:   str     r3, [r7, #44]   ; 0x2c
08000714:   ldr     r3, [r7, #44]   ; 0x2c
08000716:   ldr     r2, [pc, #12]   ; (0x8000724 <main+140>)
08000718:   cmp     r3, r2
0800071a:   ble.n   0x80006d0 <main+56>

34 Inst pro loop dauert 25sec = 1.36 IPC
Dieses Testset hat sehr wenige Abhängigkeiten, dafür int divisionen.

for(i=0;i<480000000;i++){
      k=k&k;
      l++;
      m=m|m;
      n=n-1;
      o=o;
      p=p|p;
      s=s;
      t=t&t;
    }

Hat erneut nahe 1 IPC obwohl nur simple instruktionen und wenige 
Abhängigkeiten... Wie kommt ST auf ihr IPC von 2.7?

Gem. Arm datenblatt zum M7 hat der keine out of order ex. Ist zwar 
superscalar aber nur in der Minimalausführung 2 Alu und 2 L/S (+DSP 
ALU).

Mehr als 1.3 IPC werden so wohl effektiv nicht drinn liegen.
Diese Performance erreiche ich jetz auch dank Stefan ⛄ F.s Tipp mit dem 
L1.

Für mehr Performance bleibt dann wohl nur OC ;-)

Code im RAM ausführen dürfte noch schneller sein.

Johannes S. schrieb:
> Code im RAM ausführen dürfte noch schneller sein.

Der Code wird doch schon im RAM ausgeführt ;-)

Hab gerade etwas OC versucht. Bis 650MHz lief er. Bei 700 ist er 
gecrasht. Nun habe ich das problem:

Target not halted after reset.
Target not halted

Error in initializing ST-LINK device.
Reason: Target not halted.

Das ich den nicht mehr JTAGEN kann.

Wie kann man das lösen?

FGPA schrieb:
> Hab gerade etwas OC versucht. Bis 650MHz lief er. Bei 700 ist er
> gecrasht. Nun habe ich das problem:
>
> Target not halted after reset.
> Target not halted
>
> Error in initializing ST-LINK device.
> Reason: Target not halted.
>
> Das ich den nicht mehr JTAGEN kann.
>
> Wie kann man das lösen?

Uber USB konnte ich das Flash resetten...
690MHZ scheint bei meinen die grenze zu sein, wobei zu beachten ist, 
dass ich nicht alle befehle getestet habe.
Dennoch: Es sieht gut aus, dass der H7 ein gewisses OC potential haben 
könnte...
Mit 1.3 IPC hat man bis zu. 900 RISC MIPS für unter 10EUR -> 90 RISC 
IPS/Eur
Beim PC erhält man 15 IPC mit 4GHz = 60000 CISC MIPS  für 42Eur (12 
Kerne für 500 EUR) -> 1440 Cisc MIPS/EUR

Der Vergleich ist ein bisschen Apfel/Birne. Aber bezüglich 
Rechenleistung sind schon Welten unterschied... Dennoch der H7 scheint 
ein solider uC zu sein...

m.n. schrieb:
> Der Code wird doch schon im RAM ausgeführt ;-)

Im L1 ;-)