DMA für Can beim STM 32

Nach wälzen des Datenblattes habe ich einen möglichen Fehler entdeckt. 
Der Can besitzt ja 3 Puffer für Nachrichten. Mit der oben genannten 
aktion wird aber nur maximal 1 Nachricht pro Interrupt geholt. So steht 
in den Beispielen von ST.
Ich denke das ich das Pending benutzen muss im Interrupt um den Fifo 
jedesmal geleert zu haben bevor ich den Interrupt verlasse.

Mit dem DMA steht die Frage aber immer noch, ich suche ja eine Lösung um 
den ständigen Interrupt noch zu vermeiden.

Abeitest Du mir STM32F103 oder STM32F105/7. Falls Du auch USB beim 103 
benutzt, könnte der gemeinsam genutzte Speicher ein Problem sein.

ne,ich benutze nur can

Genaugenommen benutze ich einen 103 als Slave und einen 105 als Master 
gleichzeitig. Das ganze ist ja eine Multibusanwendung als eine eigene 
Hausbusangelegenheit. Ist auf beiden auch das gleiche Problem. Da sollen 
bei mir ca. 20 Teilnehmer rankommen.
Ich werde erstmal die Fifo Geschichte genau prüfen, wenn ich wieder Zeit 
habe.
DMA habe ich bis jetzt noch nicht benutzt, kenne das aber von anderen 
Steuerungen.

mmh, ich habe das ganze jetzt mal mit Pending probiert, naja, besser ist 
es nicht geworden. Der Interrupt wird wohl solange immer wieder 
angesprungen bis der Fifo leer ist. Meine Variante beschleunigt das 
ganze somit nur um die Zeit des Interrupts selber und hilft natürlich 
unnötige unterbrechungen zu vermeiden.

Hab mal mit Debugger nachgesehen. Bei 8Byte Can Nachrichten und 16ms 
dazwischen kann es vorkommen, dass der Puffer überläuft.
Verstehe ich nicht so ganz.
Was macht der zum Teufel die ganze Zeit??

Also mein Interrup sieht so aus, mit Software Ringpuffer. Natürlich habe 
ich den auch mal Testweise abgeschaltet.
Mit ab zähle ich halt die Anzahl der messages. Da ein Peakcan sendet und 
der andere alles empfängt gehe ich davon aus, das Hardwaremäßig alles 
stimmt.


void USB_LP_CAN_RX0_IRQHandler(void)
{
  CanRxMsg canmsg;
  while (CAN_MessagePending(CAN_FilterFIFO0)!=0)
  {
    CAN_Receive(CAN_FilterFIFO0, &canmsg);
    //can_send_rxring(canmsg);
    ab++;
  }

}

So, habe es mal nachgemessen. Der stm benötigt ca 14Mikrosekunden um die 
Interruptschleife abzuarbeiten. Den Rest hat er Zeit (while (1);)

Keiner eine Idee?

Danke für die Antworten, hier mal ein paar Tests.
@Markus

Genauso hatte ich die Schleife ja, aber es wird dann nur eine einzige 
Can Nachricht abgerufen pro Interruptaufruf. Durch die Abfrage des Fifo 
Anzeigers kann ich ja eine gerade hinzugekommende auch gleich mit 
abfragen.

@beide

Ich bin in der glücklichen Lage in der Firma einen Hardware Debugger zu 
haben und mit dem Trace konnte ich genau sehen das ein kompletter 
Interrupt Aufruf mit Abspeichern in meinen Ringpuffer 14us vergehen. 
Sonst läuft gar nichts mehr. In der main steht nur noch while(1); 
Entlosschleife.
Ein Versuch, einfach den Systick zu nutzen und alle ms eine Abfrage des 
Can Busses zu machen schlägt ebenso fehl. Scheint so als wenn der Can 
Bus für ne Zeit gesperrt ist.

Bei der Überwachung der Can Register zeigt sich das 1 bis 2 Nachrichten 
in den Fifo gehen bei 20ms Nachrichtenabstand. Bei 15ms Abstand sind es 
drei und werden ab und an dann eben vier was einen Überlauf erzeugt und 
die Nachricht futsch ist. Da ja nach 14us eigendlich alles erledigt ist 
finde ich keine Erklärung. Das die Libs nicht optimal programmiert sind 
ist klar.
aber da ich ja nichts anderes mache zur Zeit "egal".

Der Prozessor läuft auf 72Mhz und der ABB auf 32. Sonst würde auch keine 
Nachricht gesendet werden wenn diese Einstellung nicht stimmen würde.

Die Initialisierung ist nach Beispielen der Libs wieder zurückentwickelt 
um Fehler auszuschließen und entspricht momentan genau dem Beispiel für 
1Mbit. Wie gesagt verhält es sich auch bei 20kBit genauso.

Das ganze Programm hat also nur die Initialisierung, Filter offen und 
natürlich an, sowie die gpios, Freigabe des Interrups und die 
entsprechende Nvic Programmierung. Prioritäten habe ich auch mal auf 
null geändert ohne Wirkung.

Da der 103 keinen DMA für Can hat stehe ich auch etwas aufn Schlauch. 
Ich benötige das schnelle senden zunächst nur für einen bootloader, aber 
es nervt mich irgendwie Daten verlieren zu können.
Es würde mich natürlich mal interessieren wer seinen Can ähnlich 
bombadiert, ansonsten merkt man den Fehler ja nicht.

Ergänzung: Ich kopiere die originale Can Nachricht Struktur in ein Array 
und setze nur einen Zähler, mehr nicht. Auseinander genommen wird sie 
dann in der main. Ich muss aber immer wieder sagen das alles in 14uS 
abgeschlossen ist. Demnach hat er eigendlich genügend zeit. Ich habe das 
mal so gerrechnet:
130bits dauert eine Nachricht mit 8 Datenbyte und allem Gedönse. Stand 
irgendwo im Netz.
1000000/130=7692 mögliche theoretische Nachrichten wenn kein Abstand 
besteht. Also 1/7692=130uS pro Nachricht.
Das wiederum bedeutet 130-14= 116 uS Zeit die die Cpu verwenden kann.
Da der Fehler aber auch bei niedrigen Taktraten auftaucht und da ms 
zwischen den "möglichen" Interrups liegen muss (meiner Meihnung nach) 
bei einem dreifachen FIFO in Hardware genug zeit sein. Bitte korrigiert 
mich wenn ich da einen Denkfehler habe.

"Irgentwie erkennst du den Füllstand des (Hardware-)FIFOs nicht.

Na ja, irgendwie schon, ich sehe mit dem Debugger ja in Echtzeit wie er 
voll wird.
Mir kommt es nur komisch vor das er so lange intern braucht bis er 
wieder bereit ist neue Telegramme aufzunehmen. Es muss sich ja um 
Millisekunden handeln wenn ich schon beim senden immer 1ms zwischen den 
Telegrammen habe.
Wie kann man den abschalten?

@Markus
Habe zwar nicht in der while gepollt, aber in der Systick, werde es aber 
auch mal versuchen.

Es ist mir etwas peinlich, aber auch das muss gesagt werden:

Ich habe mich sozusagen selbst verarscht. Der Debugger hat einen 
Echtzeit und einen Monitor Modus, Ich hatte zusätzlich den MonitorModus 
eingestellt wo der Debugger 500us zugriff hat und alles unterbricht bis 
dahin.

Klasse wenn man sich mit seinen Tools auskennt!

Danke für die Hilfe, es hat wie immer etwas gebracht, auch wenn es 
schmerzt.