Hi, ich habe hier ein Projekt, bei dem ein Timer zyklisch eine ADC-Sequenz auslöst. Die Ergebnisse der 4 Kanäle sollen per DMA ins RAM geschrieben werden. Im DMA-Interrupt sollen die Daten dann weiter verarbeitet werden. Nun habe ich das Problem, dass immer ein Half-Transfer und ein Transfer-Complete Interrupt ausgelöst wird. Den Half-Transfer-Interrupt benötige ich nicht und könnte ihn deshalb deaktivieren. Leider sieht der HAL-Treiber das nicht vor. In der Funktion HAL_DMA_Start_IT() werden grundsätzlich alle 5 DMA-Interrupts aktiviert. Muss ich nun am Treiber vorbeiprogrammieren, um das zu ändern? Ich könnte den Treiber ändern, jedoch führt jede Änderung im CubeMX dazu, dass der Treiber wieder auf den Originalstand gebraucht wird. Michael
Hallo, du kannst dir ja deine eigene HAL_DMA_Start_IT-Funktion programmieren, so habe ich das Problem umgangen. Gruss CS
Moin, trotzdem muss ich ja dann den Treiber ändern. Da ich mit CubeMX arbeite, wird diese Änderung dann ja bei jeder Config-Änderung wieder rückgängig gemacht. Das ist zwar beherrschbar aber lästig und irgendwie unsauber. Michael
Michael S. schrieb: > Moin, > trotzdem muss ich ja dann den Treiber ändern. > Da ich mit CubeMX arbeite, wird diese Änderung dann ja bei jeder > Config-Änderung wieder rückgängig gemacht. > Das ist zwar beherrschbar aber lästig und irgendwie unsauber. > > Michael Wer zwingt dich denn die HAL_DMA_Start_IT aufzurufen? Schreib deine eigene Funktion mit anderem Namen und kopiere von mir aus 90% des Codes dieser Funktion. Dann sorgt der Linker schon dafür dass die originale HAL_DMA_Start_IT auf wundersame Weise aus deinem Projekt verschwindet... Nachdem alles andere konfiguriert ist, sollte sich das ganze doch wohl nur um ein ein paar wenige Bits in wenigen Registern handeln. Ich kann überhaupt nicht verstehen wie man sich den ganzen HAL-Kram überhaupt antun kann. Außer um mal ein paar Samples durchzuspielen. Aktuell steige ich in den STM32F334 ein. Das Referenzmanual ist 1121 Seiten lang und an manchen Stellen nicht gerade logisch und verständlich geschrieben. Wenn man das aber halbwegs verstanden hat, weiss man was mit dem Controller geht und was nicht. Bei der ganze HAL-Geschichte muss man das auch noch aus der spärlichen Doku erahnen. Eigentlich versteht man die ohne das Ref-Manual nicht mal. Wozu dann doppelt lernen? Allein die HAL_RCC_OscConfig-Funktion besteht aus ca. 250 Zeilen Code. Die meisten Projekte setzen am Anfang einmal den Takt und gut ist. Dafür braucht man 5 Zeilen Code. Man kann ja der Meinung sein mit dem Einsatz von CubeMx spart man sich die Einarbeitung in die Dokumentation, aber auf so einen Blindflug hätte ich keinen Bock.
Du könntest den Half Transfer Complete Interrupt auch einfach drinnen lassen, wenn du die Libraries nutzen willst? Die paar Nanosekunden bringen einen in den wenigsten Fällen um... temp schrieb: > Michael S. schrieb: >> Moin, >> trotzdem muss ich ja dann den Treiber ändern. >> Da ich mit CubeMX arbeite, wird diese Änderung dann ja bei jeder >> Config-Änderung wieder rückgängig gemacht. >> Das ist zwar beherrschbar aber lästig und irgendwie unsauber. >> >> Michael > > Wer zwingt dich denn die HAL_DMA_Start_IT aufzurufen? Schreib deine > eigene Funktion mit anderem Namen und kopiere von mir aus 90% des Codes > dieser Funktion. Dann sorgt der Linker schon dafür dass die originale > HAL_DMA_Start_IT auf wundersame Weise aus deinem Projekt verschwindet... > > Nachdem alles andere konfiguriert ist, sollte sich das ganze doch wohl > nur um ein ein paar wenige Bits in wenigen Registern handeln. > > Ich kann überhaupt nicht verstehen wie man sich den ganzen HAL-Kram > überhaupt antun kann. Außer um mal ein paar Samples durchzuspielen. > Aktuell steige ich in den STM32F334 ein. Das Referenzmanual ist 1121 > Seiten lang und an manchen Stellen nicht gerade logisch und verständlich > geschrieben. Wenn man das aber halbwegs verstanden hat, weiss man was > mit dem Controller geht und was nicht. Bei der ganze HAL-Geschichte muss > man das auch noch aus der spärlichen Doku erahnen. Eigentlich versteht > man die ohne das Ref-Manual nicht mal. Wozu dann doppelt lernen? > Allein die HAL_RCC_OscConfig-Funktion besteht aus ca. 250 Zeilen Code. > Die meisten Projekte setzen am Anfang einmal den Takt und gut ist. Dafür > braucht man 5 Zeilen Code. Man kann ja der Meinung sein mit dem Einsatz > von CubeMx spart man sich die Einarbeitung in die Dokumentation, aber > auf so einen Blindflug hätte ich keinen Bock. Ich kann überhaupt nicht verstehen wie man den ganzen HAL-Kram nicht nutzen kann... Diese Libs sind halt nicht dafür gedacht mal eben eine LED zu toggeln und 2x Bytes via Serieller irgendwohin zu schicken. Wenn du aber mal 19 Tasks laufen hast, die in in zig Abhängigkeiten das selbe Modul nutzen wollen, dann wirst du froh sein wenn die Library das entsprechende Modul an den richtigen Stellen mal eben vor einem Zugriff schützt... und das ganze ohne sich darüber Gedanken machen zu müssen. Ich persönlich wähl auch oft den Mittelweg und lass mir meine Peripherie etwa initialisieren, bevor ich mich selbst Stunden quälen muss. Letztes Beispiel hier ist etwa die neue SAI-Schnittstelle. Ja ich will einen 64bit I2S-Frame mit einem 32bit langen Wordselect und einen 2048kHz Bitclock, der mit 16bit Daten schickt. Wozu dabei Bit13-16 des SAI1-BlockA CR2 Registers dienen ist mir vollkommen egal.
Hi, dieser Mittelweg wirds wohl werden. Init über CubeMX/HAL und das Bedienen dann komplett selbst geschrieben. Vor allem hat man dann hoffentlich auch besser im Griff, was da genau passiert. Genau an der Stelle habe ich nämlich Tage investiert, bevor der ADC ungefähr das gemacht hat, was er soll. Try&Error Wenn man es selbst macht, hat man wenigstens ein ausführliches Reference Manual. Bei dem HAL-Zeug ist ja gerade nicht dokumentiert, was welche Funktion im einzelnen macht. Außerdem ists lahm. Michael
Vincent H. schrieb: > und das ganze ohne sich darüber Gedanken machen zu müssen. Sag ich doch. Blindflugweltmeister. Vincent H. schrieb: > Wenn du aber mal 19 Tasks laufen hast, die in in zig Abhängigkeiten das > selbe Modul nutzen wollen, dann wirst du froh sein wenn die Library das > entsprechende Modul an den richtigen Stellen mal eben vor einem Zugriff > schützt... Welches Controllermodul soll denn das sein, das von 19 Task gleichzeitig verwendet werden soll? Hier mal ein Auszug aus der HAL:
1 | #if (USE_RTOS == 1)
|
2 | #error " USE_RTOS should be 0 in the current HAL release "
|
3 | #else
|
4 | #define __HAL_LOCK(__HANDLE__) \
|
5 | do{ \
|
6 | if((__HANDLE__)->Lock == HAL_LOCKED) \
|
7 | { \
|
8 | return HAL_BUSY; \
|
9 | } \
|
10 | else \
|
11 | { \
|
12 | (__HANDLE__)->Lock = HAL_LOCKED; \
|
13 | } \
|
14 | }while (0)
|
15 | |
16 | #define __HAL_UNLOCK(__HANDLE__) \
|
17 | do{ \
|
18 | (__HANDLE__)->Lock = HAL_UNLOCKED; \
|
19 | }while (0)
|
20 | #endif /* USE_RTOS */ |
Sowas baut dir die Lib dann hunderfach in den Code ein. Das ist ja wohl ehr für die Arduino Fraktion. Die anderen kommen auch ohne diesen Mist klar.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.