[STM32] HAL vermeiden?

[Mampf F. (mampf)]

Guten Mittag!

nach viel Lesen hab ich herausgefunden, dass es eine Vendor-unabhängige 
Standard-Library CMSIS gibt, die ST mit ihrem HAL ablösen wollen.

Vermutlich geht es wieder darum, die Kunden an die eigene Library zu 
binden, damit die nicht so leicht auf einen anderen Hersteller wechseln 
können.

Mittlerweile - ich bin STM32-Anfänger - hab ich CubeMX installiert, die 
Konfiguration durchgeführt, Code erstellen lassen, diese per 
CubeMX2Makefile in ein Eclipse-verwertbares Makefile konvertieren und 
importieren lassen und soweit kompiliert alles.

Der Code ist halt voll mit dem HAL-Zeug. Aber die Peripherie und 
Clock-Generatoren und und und alles per CMSIS zu machen, erscheint mir 
erstaunlich komplex und aufwändig.

Da ich vor habe, USB zu verwenden, würde mir das einfacher erscheinen, 
die USB-HAL-Funktionen zu verwenden, aber ich bin mir unsicher, ob ich 
nicht doch lieber Maple-Mini USB-Examples suchen soll, die nur CMSIS 
verwenden, da im Prinzip mein Custom-Board der Minimal-Schaltung des 
Maple-Minis entspricht.

Was würdet ihr machen? HAL verwenden?

VG
Mampf

[Schorsch X. (bastelschorsch)]

Es hindert dich doch keiner es mal auszuprobieren und uns an deiner 
Erfahrung teilhaben zu lassen. Ich hab CubeMx mal mit USB als COM Port 
ausprobiert und es hat mit wenig Aufwand funktioniert. Ob das der 
Weisheit letzter Schluß ist, sei mal dahin gestellt. Und für die 
Konfiguration der relativ komplexen Takterzeugung ist CubeMx auch nicht 
das schlechteste.
Der Rest funktioniert bisher einigermaßen und wenn nicht, kann man das 
auch neu erfinden.

[Marc V. (Firma: Vescomp) (logarithmus)]

Mampf F. schrieb:
> nicht doch lieber Maple-Mini USB-Examples suchen soll, die nur CMSIS
> verwenden, da im Prinzip mein Custom-Board der Minimal-Schaltung des
> Maple-Minis entspricht.

 Wir verwenden (unter anderem) sowohl Maple-Mini als auch Blue Pill.


> Was würdet ihr machen? HAL verwenden?

 Was spricht dagegen (zumindest am Anfang) ?

 Ich glaube das wird in einen Glaubenskrieg ausarten (wie etwa mit
 Arduino) - da ging es auch um total unwichtige Dinge.
 Ob der Arduino mit Arduino-IDE etwas in 102.567ms ausrechnet oder
 dasselbe in GCC in 101.328ms schafft, ob er dafür 12502 Bytes oder
 11478 Bytes braucht, ist so etwas von unwichtig...

 Genauso ist es hier - CubeMX ist z.Zt. das beste Tool für STM.
 Und schon kommen die AllesBesserWisserExperten angerannt, die einen
 ARM mit einem nur einigermassen komplexem Program aus dem Kopf zum
 Laufen bringen wollen, behaupten dass CubeMX grosser Mist sei usw.

 Über HAL kann man geteilter Meinung sein, aber über CubeMX nicht.
 Und BTW, ich habe bis jetzt auch keine schlüssigen Argumente gehört
 die gegen HAL sprechen.

 Als STM Anfänger solltest du (meiner Meinung nach) bei CubeMX
 und HAL bleiben, später kannst du immer noch von HAL auf etwas
 anderes umsteigen.
 Aber CubeMX solltest du behalten (zumindest, solange du dich mit
 STM rumschlägst).

 Nur meine Meinung...

[Mampf F. (mampf)]

Marc V. schrieb:
>  Und schon kommen die AllesBesserWisserExperten angerannt, die [...] behaupten 
dass CubeMX grosser Mist sei usw.
>
>  Und BTW, ich habe bis jetzt auch keine schlüssigen Argumente gehört
>  die gegen HAL sprechen.
>
>  Als STM Anfänger solltest du (meiner Meinung nach) bei CubeMX
>  und HAL bleiben

Ok, hört sich sinnig an, dann werde ich HAL verwenden.

Alles andere wären wohl nur idologische Gründe ... Aber da ich nicht vor 
habe, irgendwelche allgemeinverwendbaren Libraries zu bauen oder meinen 
Code als Obergott zu publizieren, der sich damit brüstet, ohne HAL 
auszukommen, ist es sowiso egal xD

[Schorsch X. (bastelschorsch)]

Bis sowas einigermaßen fehlerfrei ist, gibt es schon die übernächste 
Generation STM32 o.ä. Ich möchte CubeMx auf keinen Fall schlecht reden, 
es ist ein schönes tool, um überhaupt mal Leben in sowas wie einen STM32 
zu bringen. I.a. ist in den neuen Derivaten mehr als genug Speicher, 
dass es auf ein paar Byte zuviel eh nicht ankommt.

[Christopher J. (christopher_j23)]

Mampf F. schrieb:
> Aber die Peripherie und
> Clock-Generatoren und und und alles per CMSIS zu machen, erscheint mir
> erstaunlich komplex und aufwändig.

Die ganz grundlegende Konfiguration von PLL und sonstigen Takten ist 
eigentlich nicht sooo wild. Bernd Kreuss hat hier auf Github ein "Bare 
Metal" Projekt für ein Nucleo-F401 angelegt: 
https://github.com/prof7bit/bare_metal_stm32f401xe

Das habe ich mir dann mal geschnappt und auf einen F103C8/F103CB 
angepasst. Den Code findest du hier: 
https://github.com/ChristianRinn/bare_metal_stm32f103c8/blob/master/Makefile]hier

Hier mal die SystemInit(), die eine PLL mit externem Quarz auf 72MHz 
konfiguriert:

WEAK void SystemInit(void) {

    /* Enable Power Control clock -> see section 7.3.8 in the manual */
    RCC->APB1ENR |= RCC_APB1ENR_PWREN;

    /* Wait for HSI to become ready */
    while ((RCC->CR & RCC_CR_HSIRDY) == 0);

    /* Disable main PLL */
    RCC->CR &= ~(RCC_CR_PLLON);

    /* Enable HSE */
    RCC->CR |= RCC_CR_HSEON;

    /* Wait until PLL unlocked (disabled) */
    while ((RCC->CR & RCC_CR_PLLRDY) != 0);

    /* Wait for HSE to become ready */
    while ((RCC->CR & RCC_CR_HSERDY) == 0);

    /*
     * Configure Main PLL
     * HSE as clock input
     * HSE = 8MHz
     * fpllout = 72MHz
     * PLLMUL = 9
     * fusb = 48MHz
     * 
     * PLL configuration is really straight forward. Setting the PLLMULL bits in the
     * RCC->CFGR to 0b0111 results in a multiplication factor of 9.
     * The divider for the USB clock is 1.5 by default, resulting in 48MHz fusb.
     * Select the HSE as PLL source by setting the PLLSRC bit in the configuration register.
     * See chapter 8.3.2 in the manual for more information.
     */
    RCC->CFGR = (0b0111 << RCC_CFGR_PLLMULL_Pos) | RCC_CFGR_PLLSRC;

    /* PLL On */
    RCC->CR |= RCC_CR_PLLON;
    
    /* Wait until PLL is locked */
    while ((RCC->CR & RCC_CR_PLLRDY) == 0);

    /*
     * FLASH configuration block
     * enable instruction cache
     * enable prefetch
     * set latency to 2WS (3 CPU cycles)
     */
    FLASH->ACR |= FLASH_ACR_PRFTBE 
                | FLASH_ACR_LATENCY_2;

    /* Set clock source to PLL */
    RCC->CFGR |= RCC_CFGR_SW_PLL;
    /* Check clock source */
    while ((RCC->CFGR & RCC_CFGR_SWS_PLL) != RCC_CFGR_SWS_PLL);

    /* Turn off HSI */
    RCC->CR &= ~(RCC_CR_HSION);

    /* Set HCLK (AHB) prescaler (DIV1) */
    RCC->CFGR &= ~(RCC_CFGR_HPRE);

    /* Set APB1 Low speed prescaler (APB1) DIV2 */
    RCC->CFGR |= RCC_CFGR_PPRE1_DIV2;

    /* SET APB2 High speed prescaler (APB2) DIV1 */
    RCC->CFGR &= ~(RCC_CFGR_PPRE2);

    /* allow debug even during sleep modes (otherwise debugger would be of little use) */
    DBGMCU->CR |= DBGMCU_CR_DBG_SLEEP
                | DBGMCU_CR_DBG_STANDBY
                | DBGMCU_CR_DBG_STOP;

    SystemCoreClock = 72000000UL;
}

Wenn man im Manual die Beschreibung zum Control Register (CR) und 
Configuration Register (CFGR) im Kapitel "reset and clock control" 
gelesen hat, sowie den "clock tree" (Figure 8) kennt bzw. sich mal im 
CubeMX die Takte durchkonfiguriert hat, dann ist das nicht mehr so ein 
großes Ding.

Mampf F. schrieb:
> Da ich vor habe, USB zu verwenden, würde mir das einfacher erscheinen,
> die USB-HAL-Funktionen zu verwenden, aber ich bin mir unsicher, ob ich
> nicht doch lieber Maple-Mini USB-Examples suchen soll, die nur CMSIS
> verwenden, da im Prinzip mein Custom-Board der Minimal-Schaltung des
> Maple-Minis entspricht.

Ja, bei USB hört meiner Meinung nach der Register-Spaß auf und ich würde 
an deiner Stelle ganz sicher auf eine fertige Bibliothek zurückgreifen. 
Wenn es mit der HAL für dich funktioniert, warum dann nicht die nehmen? 
Man muss ja nicht immer das Rad neu erfinden.

Ich bin allerdings der Meinung, dass es nicht schadet sich mal direkt 
mit den Registern auseinanderzusetzen, weil man dadurch eben besser 
lernt was die Hardware eigentlich so alles kann und wie sie es macht. 
Für das Beispiel mit der PLL-Config mag das erstmal nicht so nützlich 
erscheinen, weil man die genauso gut auch mit CubeMX machen kann oder 
von FrameworkXY bereitgestellt wird. Wenn es aber z.B. um Timer geht, 
dann sieht die Sache ganz anders aus. So ein Timer kann mit ein paar 
Registerzugriffen prima konfiguriert werden und da ist es völlig egal ob 
dein Framework bzw. Lib jetzt CubeMX/HAL, ChibiOS, mbed, Nuttx, 
STM32Duino oder wie auch immer heißt. Den CMSIS-Header binden eben fast 
alle ein (libopencm3 ist das einzige Beispiel was ich kenne, wo das 
nicht der Fall ist). Die Frage ist also nicht zwingend FrameworkXY oder 
Register (CMSIS), da es genauso gut FrameworkXY und CMSIS sein kann.

[Markus M. (Firma: EleLa - www.elela.de) (mmvisual)]

Ich arbeite schon über 10 Jahre mit STM32, habe auch schon diverse Libs 
und HALs hinter mir.
Aber das was beim CubeMX raus kommt finde ich einfach nur klasse.
Und wenn man nur im Usercode Bereich der main.c was ändert, kann man 
auch problemlos im Nachhinein noch was mit CubeMX ändern und den Code 
neu generieren lassen. CubeMx kopiert dann automatisch den eigenen Code 
in die neue main.c zurück. Der Usercode ist ohnehin in extra Dateien.

[Gerd E. (robberknight)]

War erst vor ein paar Tagen ein ziemlich ähnlicher Thread hier:
Beitrag "(ST) ARM Programmierung - HAL, SPL, CMSIS"

[Bernd K. (prof7bit)]

Christopher J. schrieb:
> Ja, bei USB hört meiner Meinung nach der Register-Spaß auf

Auch das geht noch wenn man sich wirklich reinbeißen will und mal ein 
paar Wochenenden und Nächte opfert, sich das Buch "USB Complete" besorgt 
(und so lange liest bis man Layer 1 und 2 verstanden hat, ist gar nicht 
so wild) und sich dann andere existierende Treiber anschaut und 
durchackert. Am Ende wird es dann einfacher sein als man zunächst 
befürchtet hat.

Hier hab ich mal ein Beispiel für Kinetis MKL25 (kein STM32 aber die 
Komplexität dürfte vergleichbar sein). Das folgende implementiert ein 
generisches HID-Device (treiberlos), und über dieses einen 
bidirektionalen Stream mit fifo-Puffern in beide Richtungen: 
https://github.com/prof7bit/frdm-kl25z-minimal-usb-hid/blob/master/src/usb/usb_device.c

[Wühlhase (Gast)]

Ich persönlich kann die HAL auch nicht sonderlich leiden. Wenn ich mir 
allein die Funktion zum Auswerten der SPI-Schnittstelle ansehe...pfui. 
ca. 100 Zeilen Code, nur um (im Wesentlichen) ein Register auszulesen.

Klar, die 100 Zeilen sind ja nicht unnütz, da werden alle möglichen 
Kollisionen abgefangen, Interupts gelockt, Errorhandler ausgewertet, 
usw. usf. Aber zumindest ich habe keine so komplizierten Projetkte, bzw. 
sorge selber dafür, daß nichts kollidiert. Dafür hat man im Prinzip aber 
einen wesentlichen Teil der Kontrolle über seinen Code aufgegeben und 
muß sich halt auf die Bibliothek verlassen. Gerade wenn man aus der 
AVR-ASM-Ecke kommt ist das häßlich.

Wie aber meine Vorredner schon bestätigten-die CubeMX ist einfach nur 
super. Hat nur einen Nachteil: Verleitet noch mehr Leute lieber dumme 
Fragen zu stellen als sich mal rasche selber im Handbuch schlau zu 
machen.

[Schorsch X. (bastelschorsch)]

Ich kapier den ganzen Bohei nicht.
Wer es (CubeMx, Hal, CMSIS) benutzen will, soll es tun - wer nicht  -> 
soll´s eben lassen.

Ein jeder darf sich Funktionen schreiben, wie er lustig ist. Bis dann 
endlich mal die Ports ordentlich funktionieren - ist denn schon wieder 
Weihnachten...

Wenn man mit der ganze uComputerei seinen Lebensunterhalt verdienen 
muss, dann sieht alles immer ganz anders aus.

Die meisten von Euch fahren doch auch mit einem Auto, ohne eines 
konstruieren und fertigen zu wollen/können/dürfen.

Bei Datenblättern von 149 Seiten und Ref-Manuals von 1419 Seiten für 
einen einzigen STM32 - derer es ja Hunderte gibt - ist das alles doch 
ganz schön, wenn es erstmal läuft. Die Feinheiten kann man dann ändern, 
wenn es nötig ist.

Noch viel Spaß beim Bits und Beits zertreten....

[Mampf F. (mampf)]

Also mittlerweile hab ich mein Custom-Board mit einem 2EUR-STLinkV2 
Adapter unter Linux und Eclipse am Laufen und bin gleich in das erste 
Problem gestolpert ...

CubeMX hatte irrtümlich das hier erzeugt:

RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI|RCC_OSCILLATORTYPE_HSE
                              |RCC_OSCILLATORTYPE_LSE;

Die Funktion meldete HAL_ERROR zurück und blieb in einer while(1){} 
Schleife, die für die Fehlerbehandlung da ist, hängen.

Keine Ahnung, weshalb der HSI da aktiviert wurde - ich seh den Grund 
auch in CubeMX selbst nicht ... Aber nachdem ich den 
RCC_OSCILLATORTYPE_HSI auskommentierte, funktionierte der Rest und 
seitdem idelt der µC in der main while(1)-Loop, wie es sein sollte und 
es gab auch keine HAL_TIMEOUT-Fehler wegen fehlerhaftem externen 
Oszillator oder soetwas - also wohl wirklich ein Logikfehler des 
Programms, das zu ungültigen/unvollständigen Parametrisierungen führte.

Naja, tolle Tools ... Machen wieder einen prima Eindruck! ;)

Ohne Debugger hätte ich das niemals gefunden ... Glück gehabt :)


Hat jemand eine Idee, wieso CubeMX das gemacht hat?

Ach super ...




This bug was introduced by CubeMX v4.20.
In SystemClock_Config() function, when HSE is selected it generates 
code:

RCC_OscInitTypeDef RCC_OscInitStruct; 
RCC_ClkInitTypeDef RCC_ClkInitStruct;

/**Initializes the CPU, AHB and APB busses clocks 
*/ 
RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI|RCC_OSCILLATORTYPE_HSE; 
RCC_OscInitStruct.HSEState = RCC_HSE_ON; 
RCC_OscInitStruct.HSEPredivValue = RCC_HSE_PREDIV_DIV1; 
RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON; 
RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE; 
RCC_OscInitStruct.PLL.PLLMUL = RCC_PLL_MUL9; 
if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK) 
{ 
  Error_Handler(); 
}

Notice the OscillatorType filed is initialized for BOTH HSI and HSE, 
while later field HSIState is never set.

So you have two solutions:

either remove RCC_OSCILLATORTYPE_HSI for the line to be like this:
RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;
or add HSIState field like this:
RCC_OscInitStruct.HSIState = RCC_HSI_ON;

I hope they will fix this ASAP, as you have to edit SystemClock_Config() 
every time the project is regenerated..


Quelle: http://www.openstm32.org/forumthread4665

Blöder Schrott ;-)

[Mampf F. (mampf)]

Hab jetzt den HAL-Kram doch aus meinem Projekt geworfen ... War mir 
höchst unsympathisch - und viele Tutorials verwenden es nicht, weshalb 
man ständig übersetzen müsste :)

Die Clock-Geschichte passiert mit einem Standard-Projekt des 
ARM-Eclipse-Plugins automatisch, man muss nur noch einen Define auf 
48MHz setzen, dann ist HSE + PLL schon richtig eingestellt (netterweise 
nehmen sie einen 8MHz externen Quarz an :) )

Danke nochmal für euren Input! :)

VG
Mampf

[Christopher J. (christopher_j23)]

Bernd K. schrieb:
> Auch das geht noch wenn man sich wirklich reinbeißen will und mal ein
> paar Wochenenden und Nächte opfert, sich das Buch "USB Complete" besorgt
> (und so lange liest bis man Layer 1 und 2 verstanden hat, ist gar nicht
> so wild) und sich dann andere existierende Treiber anschaut und
> durchackert. Am Ende wird es dann einfacher sein als man zunächst
> befürchtet hat.
>
> Hier hab ich mal ein Beispiel für Kinetis MKL25 (kein STM32 aber die
> Komplexität dürfte vergleichbar sein). Das folgende implementiert ein
> generisches HID-Device (treiberlos), und über dieses einen
> bidirektionalen Stream mit fifo-Puffern in beide Richtungen:
> 
https://github.com/prof7bit/frdm-kl25z-minimal-usb-hid/blob/master/src/usb/usb_device.c

Ja man kann das machen und tatsächlich sieht dein HID-Device sehr 
übersichtlich aus und die Registermimik ist bei USB ja gar nicht mal so 
wild, dafür eben der ganze USB-Stack kram umso mehr. Ich würde 
jedenfalls einen Ein- bzw. Umsteiger eher auf die Aspekte von Timern, 
ADC, DAC, DMA, usw. loslassen und stattdessen eine fertige 
Implementierung für USB nehmen. Respekt aber dafür das du das gemacht 
hast. Warum eigentlich? Eigene Tastatur oder BadUSB vielleicht?

Edit: Ahhhh irgendwie hat er das Bild erst gar nicht angehängt und dann 
beim nachträglichen Anhängen gleich vier mal :D

Mampf F. schrieb:
> Also mittlerweile hab ich mein Custom-Board mit einem 2EUR-STLinkV2
> Adapter unter Linux und Eclipse am Laufen und bin gleich in das erste
> Problem gestolpert ...

Ja fehlerfrei ist das CubeMX auf keinen Fall. Hab mal bei meinem 
Nucleo-F411RE die Takte wie im angehängten Bild konfiguriert (mit HSE im 
Bypass Modus, eigenes Projekt, kein generierter Code). Bei Benutzung von 
Timer 2 ist mir das dann immer wenige Sekunden nach dem Reset 
abgeschmiert. Auf der Suche nach der Lößung bin ich dann im RefMan auf 
das hier gestoßen:

> Bits 12:10PPRE1: APB Low speed prescaler (APB1)
> Set and cleared by software to control APB low-speed clock division factor.
> Caution:The software has to set these bits correctly not to exceed 42 MHz on
> this domain.

Also mal testweise den Systemtakt von 96 MHz auf 84 MHz reduziert und 
damit eben auch den APB1 Takt auf 42 MHz und siehe da, das Ding läuft 
stabil. Vielleicht habe ich auch sonst irgendwas falsch gemacht aber 
irgendwie ist es schon komisch, das im Refman max. 42 MHz und im CubeMX 
max. 50 MHz steht und die Kiste abstürzt wenn man 48 MHz nimmt aber 
läuft wenn es nur 42 MHz sind.

[Marc V. (Firma: Vescomp) (logarithmus)]

Christopher J. schrieb:
> stabil. Vielleicht habe ich auch sonst irgendwas falsch gemacht aber
> irgendwie ist es schon komisch, das im Refman max. 42 MHz und im CubeMX
> max. 50 MHz steht und die Kiste abstürzt wenn man 48 MHz nimmt aber
> läuft wenn es nur 42 MHz sind.

 Kann passieren, ARM ist eben kein AVR.

 Was ich aber richtig komisch finde, sind Leute die behaupten,
 die haben das alles im Kopf, überhaupt kein Problem...

[meckerziege (Gast)]

Mampf F. schrieb:
> Hab jetzt den HAL-Kram doch aus meinem Projekt geworfen ... War
> mir
> höchst unsympathisch - und viele Tutorials verwenden es nicht, weshalb
> man ständig übersetzen müsste :)

Ebenso hier.

Bin ein Verfechter der Bare-Metal programmierung. Habe das für mich(!) 
und meine Anwendungen als das sinnvollste identifiziert.

[Christopher J. (christopher_j23)]

Marc V. schrieb:
> Was ich aber richtig komisch finde, sind Leute die behaupten,
>  die haben das alles im Kopf, überhaupt kein Problem...

Naja, nochmal wird mir das jedenfalls nicht passieren. Gebranntes Kind 
und Feuer... Das bleibt hängen.

Sorry übrigens für das völlig überflüssige viermalige Posten des Bildes. 
Ursprünglich war es gar nicht hochgeladen worden und dann beim 
nachträglichen Bearbeiten hab ich dann mehrmals auf "Weitere Datei 
anhängen" geklickt in der Hoffnung das es dann geht aber die ist nie in 
der Liste erschienen, wie normal wenn man mehrere Dateien anhängt und 
nach absenden war sie dann halt vier mal da :D

[Nico W. (nico_w)]

Christopher J. schrieb:
> Also mal testweise den Systemtakt von 96 MHz auf 84 MHz reduziert und
> damit eben auch den APB1 Takt auf 42 MHz und siehe da, das Ding läuft
> stabil. Vielleicht habe ich auch sonst irgendwas falsch gemacht aber
> irgendwie ist es schon komisch, das im Refman max. 42 MHz und im CubeMX
> max. 50 MHz steht und die Kiste abstürzt wenn man 48 MHz nimmt aber
> läuft wenn es nur 42 MHz sind.

Da stimmt was nicht. In meinem RM steht, dass APB1 maximal auf 50MHz 
laufen darf. Und das läuft auf meinem F411RE auch problemlos. Sind die 
Waitstates richtig konfiguriert? Voltage auch?

> Several prescalers are used to configure the AHB frequency, the high-speed APB
> (APB2) and the low-speed APB (APB1) domains. The maximum frequency of the AHB
> domain is 100 MHz. The maximum allowed frequency of the high-speed APB2 domain
> is 100 MHz. The maximum allowed frequency of the low-speed APB1 domain is 50 MHz

Ich hatte meinen µC sogar schon fehlerfrei auf 125MHz am laufen. Aber 
für 100MHz ist der F411RE ja ausgelegt.

Ich fahre auch voll auf Bare Metal. Hab vor zwei Jahren mit der 
damaligen mbed(OS) angefangen und dann nach und nach den ganzen Balast 
rausgeschmissen.

Von daher hier aber mal meine Zahlen für die Clockeinstellungen für 
100MHz:

#define PLLM 4
#define PLLN 200
#define PLLP 4
#define PLLQ 8

Übrigends wird im RM auch angegeben, dass man den HSE auf 2MHz nur 
teilen soll für weniger Jitter.

[Christopher J. (christopher_j23)]

Nico W. schrieb:
> Da stimmt was nicht. In meinem RM steht, dass APB1 maximal auf 50MHz
> laufen darf. Und das läuft auf meinem F411RE auch problemlos. Sind die
> Waitstates richtig konfiguriert? Voltage auch?

Was hast du denn für eins bzw. wo liest du das denn? Bei mir (RM0383) 
steht auf S.104 bei den PPRE1 und PPRE2 Bits maximal 42MHz für APB1 und 
84MHz für APB2.

Wait states usw. hatte ich meiner Meinung nach richtig konfiguriert. Ich 
versuche mal das zu reproduzieren und lade es dann hier hoch. Jedenfalls 
hatte ich die HSE im Bypass-Mode eingestellt, damit der Takt vom ST-Link 
genutzt wird. Ich hatte in deiner Config im Teacup-Repo mal geschaut und 
da hattest du sie glaube ich nicht im Bypass-Modus.

Nico W. schrieb:
> #define PLLM 4
> #define PLLN 200
> #define PLLP 4
> #define PLLQ 8

Das gibt aber auf jeden Fall sehr runde 48MHz für USB ;)

Nico W. schrieb:
> Übrigends wird im RM auch angegeben, dass man den HSE auf 2MHz nur
> teilen soll für weniger Jitter.

Das ist wohl war. Ich hatte mir Bernds "bare-metal" Projekt für das 
Nucleo F401xE geschnappt und lediglich PLLN von 336 auf 384 und PLLQ von 
7 auf 8 hochgeschraubt, sowie eben noch die Waitstates angepasst und HSE 
auf "bypass" gestellt. Die Konfiguration ist in der SystemInit hier: 
https://github.com/ChristianRinn/bare_metal_stm32f411xe/blob/master/src/STM32F411XE/gcc_startup_system.c

[Nico W. (nico_w)]

Christopher J. schrieb:
> Das gibt aber auf jeden Fall sehr runde 48MHz für USB ;)

Bei 100MHz gibt es halt keine 48MHz. Die gibt es bei 96MHz und auch bei 
108MHz.

Für 96MHz sieht das bei mir so aus:

#define PLLM 4
#define PLLN 192
#define PLLP 4
#define PLLQ 8

Christopher J. schrieb:
> Was hast du denn für eins bzw. wo liest du das denn? Bei mir (RM0383)
> steht auf S.104 bei den PPRE1 und PPRE2 Bits maximal 42MHz für APB1 und
> 84MHz für APB2.

S.91 im RM0383. Das auf S.104 ist dann wohl nen C&P-Fehler. Bei der 
ganzen UART-Geschichte findest du ja auch keine 96MHz oder 100MHz. 
Wahrscheinlich aus dem RM vom F401 kopiert.

Wie war das noch?
Lese das RM
Lese das RM
Lese das RM
Traue nie dem RM
:D

[Mampf F. (mampf)]

Christopher J. schrieb:
> Hier hab ich mal ein Beispiel für Kinetis MKL25 (kein STM32 aber die
>> Komplexität dürfte vergleichbar sein). Das folgende implementiert ein
>> generisches HID-Device (treiberlos)

Ich hab nach ewigem Suchen soetwas auch für den STM32F103 gefunden ... 
Und zwar - man würde es nicht glauben - als Example-Code von KEIL!

http://www.keil.com/download/docs/361.asp

Das Ding besteht aus recht wenig Code und benutzt kein HAL-Kram. Ein 
paar Kleinigkeiten musste ich per Hand ändern, ein paar Kleinigkeiten 
musste ich ersetzen aber der Arbeitsaufwand belief sich auf etwa 2h ... 
:)

Mein Controller wird als "Keil"-Device nun per USB erkannt :D

([3007146.339094] hid-generic 0003:C251:1C01.0026: hiddev0,hidraw4: USB 
HID v1.00 Device [Keil Software Keil MCBSTM32 HID] on 
usb-0000:00:1d.0-1.6.1.3/input0)

Das "MCBSTM32" ist das ursprüngliche Dev-Board von denen ... Haben sich 
für den Schmarrn echt eine Device-ID gekauft ;-)

Puh, da bin ich froh - das schien schon fast aussichtslos zu sein ... 
Man findet kaum etwas im Netz

Ach was ich mich frage ... Was bringen denn eigentlich Konstanten wie

GPIO_InitStruct.GPIO_Speed = GPIO_Speed_50MHz;

wenn mein Controller auf 48MHz läuft? Das sind dann keine echten 50Mhz?!

[Chris D. (myfairtux) (Moderator)]

Mampf F. schrieb:
> Ach was ich mich frage ... Was bringen denn eigentlich Konstanten wie
>
> GPIO_InitStruct.GPIO_Speed = GPIO_Speed_50MHz;
>
> wenn mein Controller auf 48MHz läuft? Das sind dann keine echten 50Mhz?!

Das bezieht sich nicht auf die eigentliche Frequenz, die am Pin möglich 
ist, sondern auf die Eingangs-/Ausgangsfilter, die man wahlweise 
vorschalten kann, um die Flanken zu runden und so EMV-Probleme/Klingeln 
zu minimieren.

Die "Grenzfrequenzen" der Filter dürften wohl bei allen Controllern 
dieselben sein, in Deinem Fall eben 50MHz. Ob der Pin dann nur mit 48 
MHz befeuert wird, interessiert den Filter nicht :-)

Die Tabelle oben ist aus dem STM32F051x4-Datenblatt.

So habe ich das zumindest verstanden :-)

P.S.: Ich wollte das immer mal real am Oszi testen - vielleicht mache 
ich das am WE.

[STMApprentice (Gast)]

Chris D. schrieb:
> So habe ich das zumindest verstanden :-)

So ganz sicher bin ich mir da nicht, obwohl ich deine Version
nicht für unplausibel halte.

Aus meiner Sicht besteht dieses GPIO-Speed Setzen aus zwei
Dingen:

- da beim STM "alles" geclockt ist, sind es auch die GPIOs.
Alles kommt erst mit einer Clockperiode später zum Core bzw
eine Clockperiode später vom Core zum Pin. Dieser Clock
ist mittels GPIO-Speed einstellbar.

- die Spezifikation sinkt schlichtweg ab mit Erhöhung der
GPIO-Speed, d.h. als User darf man sich bei hohen Geschwindig-
keiten nicht mehr soviel Treiberleistung erwarten. Die Physik
des Pins selbst bleibt dabei aber unverändert.

Dass man sich (als Hersteller) mittels "Filtern" am Pin noch
zusätzlich Ärger einhandelt ... hmmm ich weiss nicht.

Meine 2 Cents ....  your mileage may vary ....

[Chris D. (myfairtux) (Moderator)]

STMApprentice schrieb:
> Chris D. schrieb:
>> So habe ich das zumindest verstanden :-)
>
> So ganz sicher bin ich mir da nicht, obwohl ich deine Version
> nicht für unplausibel halte.

;-)

STMApprentice schrieb:
> - da beim STM "alles" geclockt ist, sind es auch die GPIOs.
> Alles kommt erst mit einer Clockperiode später zum Core bzw
> eine Clockperiode später vom Core zum Pin. Dieser Clock
> ist mittels GPIO-Speed einstellbar.

Aber warum sollte man dann überhaupt bspw. 2MHz und nicht immer das 
Maximum setzen? Und dann gilt das ja auch noch pinspezifisch, der Port 
müsste dann unterschiedlich schnell angesprochen werden, je nach Pin.

> Dass man sich (als Hersteller) mittels "Filtern" am Pin noch
> zusätzlich Ärger einhandelt ... hmmm ich weiss nicht.

Ich meine, dass das so auch damals auf dem ST-Seminar vermittelt wurde 
- das wurde jedenfalls definitiv als "Goodie" für die EMV-Problematik 
angesprochen. Aber vielleicht hatten die auch nicht so den Plan (gibt es 
ja durchaus ;-)

Aber ich bin mir auch nicht 100% sicher.

Ich werde dazu mal Doku wälzen - irgendwo muss dazu doch Genaueres 
stehen.

Wir werden wohl um einen echten Praxistest (Ausgabe und messen per Oszi) 
nicht herumkommen. Dann haben wir Klarheit.

[STMApprentice (Gast)]

Chris D. schrieb:
> Aber warum sollte man dann überhaupt bspw. 2MHz und nicht immer das
> Maximum setzen?

Diesem Gedanken kann ich auch nicht widersprechen da er mir
so auch schon gekommen ist ....  ausser vielleicht Stromaufnahme.
Man bedenke in welchen Regionen sich der STM bewegt. Habe mal
bei einem Testprogramm am Discovery gemessen: ca 50mA bei 168 Mhz.
Bei solcher Stromspar-Hardware ist so ein Feature schon denkbar.

Chris D. schrieb:
> Wir werden wohl um einen echten Praxistest (Ausgabe und messen per Oszi)
> nicht herumkommen.

Brauchst du aber ein "gutes" Oszi. Und eine "gute" Masse. Und
ein leerlaufender Ausgangs-Pin wird dir nicht zeigen ob er
jetzt auf 25 oder 100MHz programmiert ist. Also vielleicht
ein bisschen Strom fliessen lassen.

Ich wäre gespannt auf deine Ergebnisse.

[Chris D. (myfairtux) (Moderator)]

Ich habe nochmal im Datenblatt des STM32F0 gestöbert und unter der 
obigen Tabelle noch die "Figure 23" gefunden, auf die sich die 
Frequenzangaben der Tabelle beziehen sollten (siehe Fußnote 3 unter der 
Tabelle).

Dort wird es offensichtlicher, dass diese Frequenz sich offenbar (nur) 
auf die Anstiegs- und Abfallgeschwindigkeit der Flanken bezieht.

Ich habe auch keine Stromverbrauchsangabe bezüglich der 
Speed-Einstellungen gefunden, obwohl sonst irgendwie alles angegeben 
ist.

Das würde also eher meine These stützen.

STMApprentice schrieb:
> Brauchst du aber ein "gutes" Oszi. Und eine "gute" Masse. Und
> ein leerlaufender Ausgangs-Pin wird dir nicht zeigen ob er
> jetzt auf 25 oder 100MHz programmiert ist. Also vielleicht
> ein bisschen Strom fliessen lassen.

Ja, da muss sicherlich ein Lastwiderstand dran - aber der Vergleich der 
Speed-Einstellungen sollte dann entsprechende Ergebnisse liefern.

> Ich wäre gespannt auf deine Ergebnisse.

Ich auch - wenn ich am WE dazu komme. Aber ich wollte mich eh wieder 
meiner elektronsichen Leitspindel widmen, da kann ich auf dem 
STM32F0-Discovery auch mal einige Pins für Tests zweckentfremden ;-)

[Nico W. (nico_w)]

Je nach Spannungsversorgung scheint der STM32 unterschiedliche maximale 
Frequenzen überhaupt zur verfügung stellen zu können. Theoretisch muss 
man den ja nicht auf 3,3V laufen lassen.

[m.n. (Gast)]

Die Angabe einer Frequenz ist eher als Hausnummer zu betrachten.
Mit der 'speed'-Einstellung wird die Anstiegsgeschwindigkeit der 
Ausgänge eingestellt, aber auf keinen Fall derart, als daß dort ein 
Filter oder irgendeine getaktete Logig zum Einsatz käme. Das kann man an 
den Angaben zur ext. kapazitiven Last erkennen.
Intern wird wohl ein Stromwert eingestellt; ST schweigt sich jedoch 
darüber aus.
In der Praxis zeigt sich, daß bei kleinen Werten für 'speed' die 
Signalflanken flacher verlaufen, was für viele Anwendungen ausreichend 
sein kann (z.B. USART, IIC, GPIO) und weniger Störabstrahlung 
(Oberwellen) erzeugt. Die höchste Anstiegsgeschwindigkeit ist für ext. 
Speicher (SRAM, SDRAM) notwendig.

[Micha (Gast)]

Mampf F. schrieb:
> Da ich vor habe, USB zu verwenden,

USB HID, CDC, ...?

[eagle user (Gast)]

STMApprentice schrieb:
> Chris D. schrieb:
>> Aber warum sollte man dann überhaupt bspw. 2MHz und nicht immer das
>> Maximum setzen?
>
> Diesem Gedanken kann ich auch nicht widersprechen da er mir
> so auch schon gekommen ist ....  ausser vielleicht Stromaufnahme.
> Man bedenke in welchen Regionen sich der STM bewegt. Habe mal
> bei einem Testprogramm am Discovery gemessen: ca 50mA bei 168 Mhz.
> Bei solcher Stromspar-Hardware ist so ein Feature schon denkbar.

In der "AN3430, How to achieve the lowest current consumption with 
STM32F2xx" wird die Speed-Einstellung zum Strom sparen empfohlen. Ein 
Beispiel: ein SPI-Interface mit OSPEED = 2MHz statt OSPEED = 50MHz 
betrieben reduziert den Strom um 0.1mA (bei ca. 7mA gesamt).

Aber ich glaube auch, dass es vor allem für bessere EMV gut ist.

[Mampf F. (mampf)]

Micha schrieb:
> Mampf F. schrieb:
>> Da ich vor habe, USB zu verwenden,
>
> USB HID, CDC, ...?

USB HID :)

Wobei CDC wär auch in Ordnung, das ist mir im Grunde egal, hauptsache 
USB sollte funktionieren.

Leider gibt es mit dem portierten Keil-USB-Code Probleme ... Der geht 
irgendwie schon nicht mehr und die µC landet immer in einem Fault-Vector 
sobald der EndPoint beschrieben wird ... :( Warum es einmal für 10min 
geklappt hat ... Keine Ahnung^^

Muss ich mal debuggen, vlt komme ich dahinter, woran es liegt ... So 
tief wollte ich da eigentlich garnicht einsteigen und hatte gehofft, der 
Code läuft einfach, ohne zu wissen, was er genau macht ;)

[Bernd K. (prof7bit)]

Mampf F. schrieb:
> Leider gibt es mit dem portierten Keil-USB-Code Probleme ... Der geht
> irgendwie schon nicht mehr und die µC landet immer in einem Fault-Vector
> sobald der EndPoint beschrieben wird

Eventuell Alignment-Probleme? Ohne jetzt die STM32 USB-Hardware im 
Speziellen zu kennen vermute ich dennoch daß es dort genauso wie bei 
anderen Herstellern auch gewisse Restriktionen gibt wo die 
Speicherbereiche liegen dürfen bzw an welchen Grenzen die 
Speicherbereiche aligned sein müssen auf die der USB-DMA zugreifen soll. 
Evtl beim Portieren von Keil irgendwelche diesbezüglichen Pragmas oder 
dergleichen oder entsprechende Einträge im Linkerscript unter den Tisch 
fallen lassen?

[Mampf F. (mampf)]

Bernd K. schrieb:
> Evtl beim Portieren von Keil irgendwelche diesbezüglichen Pragmas oder
> dergleichen oder entsprechende Einträge im Linkerscript unter den Tisch
> fallen lassen?

Hmm, glaube nicht ... Die ganzen "_packed" hab ich durch 
__attribute__((packed)) ersetzt. Denke, wenn das nicht stimmen würde, 
würde es garnicht gehen.

Aber Alignment hatte ich mir auch überlegt ... Jetzt zur Zeit geht es 
wieder ... Was aber auch sein könnte ... Mein 1,5k Pullup für die D+ 
Leitung war uhm angeknackst ... Irgendwann ging er dann garnicht mehr, 
ich hab ihn ersetzt und jetzt wird das Board wieder korrekt enumeriert.

Hoffe, das war es ;-)

[Mampf F. (mampf)]

Was für eine H§$%)(/§"&§e ;-)

Also jetzt hab ich es final hinbekommen und auch eine Kommunikation von 
PC<->STM32F103 ...

Schlussendlich musste ich tatsächlich auf den Vorgenerierten 
USB-CDC-Code von Cube-MX zurück greifen.

Ärgerlich, aber es funktioniert jetzt endlich ... Das USB hat mich noch 
fast um den Verstand gebracht ... Hatte mit diversen HID-Libraries und 
zwischendrin auch mal mit der Hardware zu kämpfen ... Der HID-Kram ging 
dann irgendwann auf Controller-Seite und es ließen sich auch Daten an 
den µC schicken, aber das Zurücklesen eines HID-Reports funktionierte 
nicht. Unendlich viele (fast^^) HID-Tools auf PC-Seite getestet ... Nix 
ging ;)

Traurig aber wahr: So ein USB-CDC-Projekt ist in 15min aufgesetzt, wenn 
man weiß wie ...

Also ich bleib jetzt bei HAL lol

*edit*: Ah und ich hab im Verdacht, dass mein C++ schuld war ... War mit 
meinem Projekt schon recht weit und USB hätte noch gefehlt und da hatte 
ich versucht, der Kram in mein Projekt einzubinden. Die IRQHandler waren 
per extern "C" leicht zu fixen, aber irgendwie hat es trotzdem nicht 
funktioniert. Naja, jetzt muss ich den Rest noch portieren, aber das 
dürfte an einem Vormittag erledigt sein ;)

[Bernd K. (prof7bit)]

Mampf F. schrieb:
> aber das Zurücklesen eines HID-Reports funktionierte
> nicht. Unendlich viele (fast^^) HID-Tools auf PC-Seite getestet

HID? Ich dachte Du willst CDC?

Für HID brauchst Du übrigens auch kein "Tool", Du kannst einfach mit 
CreateFile() der ganz normalen Windows-API ein Handle öffnen (den 
Dateinamen des Gerätes kannst Du mit der Setup API ermitteln) und mit 
ReadFile() kannst Du dann lesen.

Die einzigen zwei Stolpersteine sind erstens daß der Buffer den Du an 
ReadFile() übergibst exakt die Länge des HID-Reports plus eins 
beträgt, nicht mehr und nicht weniger, das nullte Byte ist für die 
Report-ID reserviert, selbst dann wenns nur eine einzige gibt. Hat der 
Buffer irgendeine eine andere Größe geht gar nichts. Ebenso beim 
Schreiben.

Und der zweite Stolperstein ist daß der verbugte generische HID-Treiber 
von Windows (7) sich weghängt wenn ein Thread im blockierenden Lesen 
steckt wärend ein anderer Thread anfangen will zu schreiben, man muss 
also vor dem Schreiben immer erst den Lesethread da kurz rauskicken 
(CancelIOEx) und mit einer CriticalSection an den zwei Stellen dafür 
sorgen daß immer nur ein Thread gleichzeitig mit dem Treiber spricht.

Dann läuft das alles wie geschmiert.

Und unter Linux nimmst Du am besten hidapi, die hat ein sehr ähnliches 
API (und ist threadsafe, read/write auf ein Handle mit der identischen 
Pufferstruktur, auch da nulltes byte = Report-ID), kann man also ohne 
Verrenkungen schön cross-platform machen.

[Mampf F. (mampf)]

Bernd K. schrieb:
> HID? Ich dachte Du willst CDC?

Ach, mir war das egal ob HID oder CDC ... Ich wollte nur Daten 
irgendwie zum µC bekommen und welche zurücklesen :)

Bernd K. schrieb:
> Und unter Linux nimmst Du am besten hidapi, die hat ein sehr ähnliches
> API (und ist threadsafe, read/write auf ein Handle mit der identischen
> Pufferstruktur, auch da nulltes byte = Report-ID), kann man also ohne
> Verrenkungen schön cross-platform machen.

Sollte man meinen ... Mit hidapi hatte ich auch mal 2h gespielt ... 
Gleiches Ergebnis^^ Es kamen zwar Daten beim Controller an (sogar die 
richtigen^^) aber Zurücklesen war scheinbar unmöglich.

Ehrlich gesagt finde ich USB äußerst komplex und wollte mich auch nicht 
in die Thematik der USB-Descriptoren einarbeiten ... Ich wollte es nur 
verwenden und kein Profi darin werden xD

Aber jetzt läuft es ja ... und der Rest ist auch portiert :)

Ärgerlicherweise musste ich IRMP auch noch für die HAL-Lib anpassen ...

Ganz ehrlich, dieses HAL-Zeug von ST ist für mich ein absolutes No-Go 
STM32-µCs in Zukunft wieder zu verwenden. Außer ich finde noch einen 
brauchbaren USB-Treiber, der auch ohne HAL gut funktioniert.

Wobei, das Problem hat sich jetzt relativiert, nachdem ich festgestellt 
habe, dass mir STCube in ein Verzeichnis, das ich ihm nicht angegeben 
habe, ein Firmware-Paket zu kopieren, in dem ein Haufen Example-Code mit 
HAL ist. Ach hätte ich das nur früher gefunden ;-)

[Bernd K. (prof7bit)]

Mampf F. schrieb:
> Ehrlich gesagt finde ich USB äußerst komplex

Wie gesagt: Wenn Du irgendwo mal ein Exemplar des Buches "USB Complete" 
rumliegen siehst: Nimm es mit. Das bringt viel Licht ins Dunkel.

[Mampf F. (mampf)]

So es gibt Updates ...

HAL ist ein Scheiß ... Wahnsinnig viel Overhead, wahnsinnig viele 
Fehler.

Beispielsweise ging SDIO-Schreiben nicht zuverlässig oder 4Bit 
SDIO-Modus ging garnicht.

Hab HAL mittlerweile komplett entsorgt und plötzlich funktioniert alles 
automagically ... Die Umstellung war nicht ganz einfach - hat mich eine 
Woche gekostet. Hat sich aber gelohnt.

Performance ist auch wesentlich besser durch weniger Overhead.

Plötzlich geht alles^^

Ahja und USB-CDC funktioniert auch ohne Probleme ... Glaub das damalige 
Problem war hardwarebedingt.

Also mein fazit: Unbedingt HAL vermeiden!

[Jan K. (jan_k)]

Und auf was hast du umgestellt? Was eigenes oder ne andere externe Lib?

[900ss (900ss)]

@Mampf
Und hat du USB-CDC jetzt auch ohne HAL in Betrieb? Wenn ja wie?

[tzhgfhgrhzfghz6453454353453534534533453453 (Gast)]

Wühlhase schrieb:
> Klar, die 100 Zeilen sind ja nicht unnütz, da werden alle möglichen
> Kollisionen abgefangen, Interupts gelockt, Errorhandler ausgewertet,
> usw. usf. Aber zumindest ich habe keine so komplizierten Projetkte, bzw.
> sorge selber dafür, daß nichts kollidiert.

das dachte ich auch immer ...

habe dann angafangen die wichtigsten sachen rauszunehmen und mich 
gefreut das ich die selbe funktion in 5 zeilen schreiben konnte
..

bis ...

...
es mal irgendwann nicht mehr so funktionierte
dann baut man wieder sicherheitsmaßnahmen ein....
und schwupps werden aus 5 doch wieder 50

wenn man dann zurückdenkt .. hätte man die HAL nehmen können .. das ding 
wäre genau so gelaufen und die letzten 2 wochen hätte man an der 
applikation arbeiten können ^^
das gilt jetzt als Bsp für funktionierende teile der Lib.

Negativbsp:

webcam -> USB Host am F7

bei USB Host hatte ich das problem mit dem Isochronen Datenempfang
der will outofthebox nicht. hier muss man die Lib etwas bearbeiten.
aber ST ist auch dankbar für informationen das sowas nicht funktioniert 
und das wandert als patch in die nächste version.

somit ist allen wieder geholfen

[Mampf F. (mampf)]

Jan K. schrieb:
> Und auf was hast du umgestellt? Was eigenes oder ne andere externe
> Lib?

Ja, im Prinzip die alten stdperiph-Libraries von ST, die nur CMSIS 
verwendeten.

Die funktionieren wirklich prima und die Funktionen sind auf das 
nötigste reduziert.

900ss D. schrieb:
> Und hat du USB-CDC jetzt auch ohne HAL in Betrieb? Wenn ja wie?

Auch hierfür gab es eine USB-Library von ST, die kein HAL verwendet.

Das war dann schnell umgesetzt und funktioniert wunderbar.

Hier die Links, die mich weiter gebracht haben:

Std-Periph-Lib:
http://www.st.com/content/st_com/en/products/embedded-software/mcus-embedded-software/stm32-embedded-software/stm32-standard-peripheral-libraries/stsw-stm32065.html

Usb:
http://www.st.com/en/embedded-software/stsw-stm32046.html

CMSIS-Lib von ARM:
https://www.arm.com/products/processors/cortex-m/cortex-microcontroller-software-interface-standard.php

Und einigen Sample-Code z.B. für (4Bit-)SDIO + FATFS:
http://mikrocontroller.bplaced.net/wordpress/?page_id=621

Auf der letzten Seite gibt es einiges an funktionierenden Beispielen, 
die allesamt nur CMSIS verwenden und auf das nötigste reduziert ist.


Dazu noch Beispiel-C++-Projekt von Gnu-Arm-Eclipse-Plugin - aber eben 
wieder um HAL reduziert (das verwendet leider HAL).

Wenn man sich bisserl damit beschäftigt, demystifiziert sich die Sache 
plötzlich enorm und man weiß, welche Files man unbedingt benötigt, wie 
die Linker-Scripts funktionieren usw ... Dann wird man HAL einfach aus 
dem Sample-Projekt raus, integriert CMSIS.

Die Sample-Projekte von dem Plugin sind aber schon ganz nett, weil sie 
doch gleich Semihosting (zB printf über SWD) , einige libc-stubs usw 
anbieten :)

[Random .. (thorstendb)]

CMSIS-Headerfiles ohne HAL könnt ihr mit SVDConv (> v3.3) aus dem 
passenden SVD file erzeugen. Der ist im ARM CMSIS Pack oder bei MDK-ARM 
(z.B. Eval) mit dabei. Die STM32 Packs gibts ebenfalls über MDK-ARM oder 
von der CMSIS Pack Website.

> SVDConv.exe STM32Fxxxx.svd --generate=header

Optional:
-b log.txt
--fields=struct

[Vincent H. (vinci)]

Random .. schrieb:
> CMSIS-Headerfiles ohne HAL könnt ihr mit SVDConv (> v3.3) aus dem
> passenden SVD file erzeugen. Der ist im ARM CMSIS Pack oder bei MDK-ARM
> (z.B. Eval) mit dabei. Die STM32 Packs gibts ebenfalls über MDK-ARM oder
> von der CMSIS Pack Website.
>
>> SVDConv.exe STM32Fxxxx.svd --generate=header
>
> Optional:
> -b log.txt
> --fields=struct


Wenn man noch mehr Fehler als in der HAL haben will, dann ja, dann kann 
man das machen.

[Mampf F. (mampf)]

Random .. schrieb:
> CMSIS-Headerfiles ohne HAL könnt ihr

Die gibt es doch ... Sind in der Std-Periph-Lib von ST (Die libs bevor 
es HAL gab) :)

[avr (Gast)]

Ich finds ja wieder Mal schön, dass Probleme mit xxx (hier stm32cube) 
auf Hersteller geschoben werden.

Ich kann die Probleme nicht nachvollziehen, denn hier funktioniert USB 
und alles andere auch mit der Hal. Anfängerfreundlich mag sie nicht 
sein, sie hat auch ihre Macken, aber auf Bugs bin ich selbst noch nicht 
gestoßen. Die alte lib finde ich in keinem Fall besser. Da fehlt mir die 
einfache portierbarkeit zwischen den stm32 Controllern.

Wenn es zu langsam ist, dann sollte man die Optimierung einschalten, 
besonders lto.

[Mampf F. (mampf)]

avr schrieb:
> Wenn es zu langsam ist, dann sollte man die Optimierung einschalten,
> besonders lto.

Najaaa ... Hast du dir mal angeschaut, was alles an Code durchlaufen 
wird, bis die eigenen Interrupt-Callback-Funktionen aufgerufen werden?

Da wird es einem schlecht! xD

Deshalb bin ich von HAL nicht überzeugt ... Die versuchen ein 
allgemeingültiges Framework über die Hardware zu stülpen ... Hat Vor- 
und Nachteile ... Nachteil definitiv, dass der Overhead zu groß ist. 
Nachteil auch, dass die Abstraktion zu hoch ist.

Man weiß schon garnicht mehr, was überhaupt passiert und darf sich in 
die Tiefe hangeln, bis man zum eigentlichen Kern vordringt.

[Vincent H. (vinci)]

Das hat man offensichtlich eh realisiert, dass da Bedarf für was 
leichteres da wär.

Aus dem Grund gibts ja jetzt die "LL" Variante, die viel direkter auf 
die Register zugreift, ohne den dem ganzen Error-Handling. In der L4 
Bibliothek gibts da schon für fast alle Peripherien was.

[avr (Gast)]

Mampf F. schrieb:
> Hast du dir mal angeschaut, was alles an Code durchlaufen
> wird, bis die eigenen Interrupt-Callback-Funktionen aufgerufen werden?

Wo genau stört es dich denn? Die Callback-Funktionen werden alle vom 
Compiler rausgeworfen, wenn du sie nicht nutzt. Wenn du Interrupts im 
MHz-Bereich nutzen solltest, spielt das vielleicht eine Rolle. Aber dann 
ist das Programmkonzept vielleicht schon falsch. Der Overhead durch den 
M3/M4-Core beträgt schon 24 Cycles.

Mampf F. schrieb:
> Nachteil definitiv, dass der Overhead zu groß ist.
Wie gesagt, ich hatte noch nie Performance-Probleme mit der HAL. Der 
Flaschenhals lag immer in der Software. Wie viele Interruptaufrufe pro 
Sekunde hast du denn? Wie viel Prozent macht die HAL tatsächlich aus? 
Für das bisschen Overhead, bekommt man ein ordentliches Errorhandling.

> Nachteil auch, dass die Abstraktion zu hoch ist.
Die könnte durchaus höher sein. Warum sollte Abstraktion ein Nachteil 
sein? Ich setze gerne eine weitere Abstraktionsschicht zwischen der HAL 
und der eigentlichen Applikation. Und damit ist die Applikation völlig 
frei auf andere Systeme portierbar.

[W.S. (Gast)]

Mampf F. schrieb:
> Deshalb bin ich von HAL nicht überzeugt ... Die versuchen ein
> allgemeingültiges Framework über die Hardware zu stülpen ... Hat Vor-
> und Nachteile ... Nachteil definitiv, dass der Overhead zu groß ist.
> Nachteil auch, dass die Abstraktion zu hoch ist.

Ich sehe da eigentlich gar keine echte Abstraktion, also was meinst du?

Hast du denn schon mal versucht, ohne all dieses Zeug auszukommen? Ich 
mach das eigentlich immer und fahre m.E. ausgezeichnet damit. Allerdings 
muß ich dazusagen, daß ich für recht viele Dinge meine eigenen 
Code-Stücke in der Tasche habe, so daß ich nicht mehr alles und jedes 
von Neuem schreiben muß.

W.S.