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
:
Bearbeitet durch User
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.
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...
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
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.
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:
1 | WEAK void SystemInit(void) { |
2 | |
3 | /* Enable Power Control clock -> see section 7.3.8 in the manual */ |
4 | RCC->APB1ENR |= RCC_APB1ENR_PWREN; |
5 | |
6 | /* Wait for HSI to become ready */ |
7 | while ((RCC->CR & RCC_CR_HSIRDY) == 0); |
8 | |
9 | /* Disable main PLL */ |
10 | RCC->CR &= ~(RCC_CR_PLLON); |
11 | |
12 | /* Enable HSE */ |
13 | RCC->CR |= RCC_CR_HSEON; |
14 | |
15 | /* Wait until PLL unlocked (disabled) */ |
16 | while ((RCC->CR & RCC_CR_PLLRDY) != 0); |
17 | |
18 | /* Wait for HSE to become ready */ |
19 | while ((RCC->CR & RCC_CR_HSERDY) == 0); |
20 | |
21 | /* |
22 | * Configure Main PLL |
23 | * HSE as clock input |
24 | * HSE = 8MHz |
25 | * fpllout = 72MHz |
26 | * PLLMUL = 9 |
27 | * fusb = 48MHz |
28 | * |
29 | * PLL configuration is really straight forward. Setting the PLLMULL bits in the |
30 | * RCC->CFGR to 0b0111 results in a multiplication factor of 9. |
31 | * The divider for the USB clock is 1.5 by default, resulting in 48MHz fusb. |
32 | * Select the HSE as PLL source by setting the PLLSRC bit in the configuration register. |
33 | * See chapter 8.3.2 in the manual for more information. |
34 | */ |
35 | RCC->CFGR = (0b0111 << RCC_CFGR_PLLMULL_Pos) | RCC_CFGR_PLLSRC; |
36 | |
37 | /* PLL On */ |
38 | RCC->CR |= RCC_CR_PLLON; |
39 | |
40 | /* Wait until PLL is locked */ |
41 | while ((RCC->CR & RCC_CR_PLLRDY) == 0); |
42 | |
43 | /* |
44 | * FLASH configuration block |
45 | * enable instruction cache |
46 | * enable prefetch |
47 | * set latency to 2WS (3 CPU cycles) |
48 | */ |
49 | FLASH->ACR |= FLASH_ACR_PRFTBE |
50 | | FLASH_ACR_LATENCY_2; |
51 | |
52 | /* Set clock source to PLL */ |
53 | RCC->CFGR |= RCC_CFGR_SW_PLL; |
54 | /* Check clock source */ |
55 | while ((RCC->CFGR & RCC_CFGR_SWS_PLL) != RCC_CFGR_SWS_PLL); |
56 | |
57 | /* Turn off HSI */ |
58 | RCC->CR &= ~(RCC_CR_HSION); |
59 | |
60 | /* Set HCLK (AHB) prescaler (DIV1) */ |
61 | RCC->CFGR &= ~(RCC_CFGR_HPRE); |
62 | |
63 | /* Set APB1 Low speed prescaler (APB1) DIV2 */ |
64 | RCC->CFGR |= RCC_CFGR_PPRE1_DIV2; |
65 | |
66 | /* SET APB2 High speed prescaler (APB2) DIV1 */ |
67 | RCC->CFGR &= ~(RCC_CFGR_PPRE2); |
68 | |
69 | /* allow debug even during sleep modes (otherwise debugger would be of little use) */ |
70 | DBGMCU->CR |= DBGMCU_CR_DBG_SLEEP |
71 | | DBGMCU_CR_DBG_STANDBY |
72 | | DBGMCU_CR_DBG_STOP; |
73 | |
74 | SystemCoreClock = 72000000UL; |
75 | } |
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.
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.
War erst vor ein paar Tagen ein ziemlich ähnlicher Thread hier: Beitrag "(ST) ARM Programmierung - HAL, SPL, CMSIS"
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
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.
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....
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:
1 | RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI|RCC_OSCILLATORTYPE_HSE |
2 | |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:
1 | RCC_OscInitTypeDef RCC_OscInitStruct; |
2 | RCC_ClkInitTypeDef RCC_ClkInitStruct; |
3 | |
4 | /**Initializes the CPU, AHB and APB busses clocks
|
5 | */
|
6 | RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI|RCC_OSCILLATORTYPE_HSE; |
7 | RCC_OscInitStruct.HSEState = RCC_HSE_ON; |
8 | RCC_OscInitStruct.HSEPredivValue = RCC_HSE_PREDIV_DIV1; |
9 | RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON; |
10 | RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE; |
11 | RCC_OscInitStruct.PLL.PLLMUL = RCC_PLL_MUL9; |
12 | if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK) |
13 | {
|
14 | Error_Handler(); |
15 | }
|
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 ;-)
:
Bearbeitet durch User
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
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.
:
Bearbeitet durch User
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...
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.
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
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:
1 | #define PLLM 4
|
2 | #define PLLN 200
|
3 | #define PLLP 4
|
4 | #define PLLQ 8
|
Übrigends wird im RM auch angegeben, dass man den HSE auf 2MHz nur teilen soll für weniger Jitter.
:
Bearbeitet durch User
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
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:
1 | #define PLLM 4
|
2 | #define PLLN 192
|
3 | #define PLLP 4
|
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
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?!
:
Bearbeitet durch User
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.
:
Bearbeitet durch Moderator
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 ....
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.
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.
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 ;-)
:
Bearbeitet durch Moderator
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.
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.
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.
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 ;)
:
Bearbeitet durch User
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?
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 ;-)
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 ;)
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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 ;-)
:
Bearbeitet durch User
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.
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!
:
Bearbeitet durch User
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
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 :)
:
Bearbeitet durch User
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
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.
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) :)
:
Bearbeitet durch User
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.
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.
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.
:
Bearbeitet durch User
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.
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.
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.