Hallo Gemeinde, ich arbeite auf einem STM32L496 (nucleo-144) Die USB-CDC-Schnittstelle hat mir CubeMx gebastelt. Senden und Empfangen geht, aber nur mit statischen Sendepuffer! Da ich aber zwischen 2 und 2k-Bytes senden werden, möchte ich dynamischen Speicher verwenden. Mit diesem Befehl werden die Daten versendet: CDC_Transmit_FS(pbuf, lenframe + SIZE_CRC); Das Verhalten ist komisch: Wenn Speicher erfolgreich (!NULL) allokiert wird (calloc()) und kein!!! free() verwendet wird geht das Senden bis das Allokieren fehlschlägt (heapsize = 0x400) Bis hierher normal... Wenn ich nach CDC_Transmit_FS() free() verwende friert die Anwendung ein. Ich prüfe auch auf (while(!hcdc->TxState)). Kann die USB-CDC-Schnittstelle nicht mit dyn. Memory umgehen? Ist es egal, ob der Pointer für calloc() lokal oder global deklariert wird? Komme hier nicht weiter. Grüße Runout
Gast
#5758022
USB beim STM32 hat dedicated RAM. Alloc gibt dir nicht das richtige.
Hallo Uwe, danke für den Tipp. in ST-UM1021 ( On-The-Go host and device library) Dedicated FIFO transmission for each of the 4 device IN endpoints. Each FIFO can hold multiple packets "dedicated RAM" ist für mich erst mal Namedropping ;-) Der Nachteil des "HAL Generierens" ist des Fehlen des detaillierten Durchblicks. Wie es aussieht, muss ich meine Puffer schon beim Kompilieren wissen. Relativ blöd... Grüße Runout
Gast
#5758244
Ich vermute, dein Problem wird dadurch ausgelöst, dass die Datenübertragung nach dem Aufruf von CDC_Transmit_FS() asynchron stattfindet. Der Puffer wird also noch länger benötigt, und zwar bis die Übertragung beendet ist.
Hallo Stefanus, war auch meine erste Vermutung. Deswegen: "Ich prüfe auch auf (while(!hcdc->TxState))" Ich schaue mal, ob es einen Int "Senden fertig / Sendpuffer leer" gibt. Einfach so mit Timer den Speicher freigeben wäre nur versuchsweise eine Lösung. Grüße Runout
Gast
#5761091
Dynamische Speicherverwaltung auf einem Microcontroller… Klar, da muss man sich echt nicht mehr wundern warum neue Geräte immer instabiler werden.