STM32 Hal-Driver ADC-DMA Interrupt

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.

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.