Hilfe mit CTL-Library

[Matze T. (gruetzwurschd)]

Hallo Leute,

ich habe ein Problem mit der Tasking Library von CrossWorks.
Es geht dabei um Folgendes:

Ich habe eine Software die das mustitasking und diverse message-queues 
nutzt.

Das Programm empfängt Daten via USB und gibt Diese an andere 
Programmteile weiter. Diese führen je nach Daten entsrechende Aufgaben 
durch.

Soweit hat das alles eigentlich okay funktioniert, bis ich mir dachte, 
dass ich noch mehr Performance rauskitzeln könnte, wenn ich die Daten 
die von der USB-ISR kommen auch noch in eine Message-Queue speichere und 
an einer anderen Stelle einfach auf ein Event warte.
--> Das funktioniert hingegen eher bescheiden. Das Problem ist, dass 
immer ein Fehler mit der Bezeichnung: "CTL_UNSUPPORTED_CALL_FROM_ISR" 
auftritt.

Das Manual schreibt, dass man beim benutzen von CTL-Funktionen in ISR's 
folgendes der ISR hinzufügen muss:

void USB_LP_CAN1_RX0_IRQHandler(void)
{
  ctl_enter_isr();  // für CTL

  USB_Istr();  // Eigentliche ISR abarbeitung
  
  ctl_exit_isr();   // für CTL
}

Kennt sich hier jemand aus? Oder weiß was ich falsch gemacht habe?

Vielleicht kann auch jemand hinweise geben was bei einem anderen RTOS 
nötig wäre um RTOS-Funktionien in ISR's zu verwenden?

Vielen Dank im Voraus für hilfreiche Beiträge

Grüße Tarkan

PS: Kann man eigentlich bedenkenlos sagen, dass die CTL_Library von 
Crossworks ein RTOS ist? Ich konnte so auf den ersten blick keine 
gravierenden Unterschiede zum freeRTOS feststellen!

[Matze T. (gruetzwurschd)]

Keiner ne Idee?

[Alex E. (tecnologic)]

Moin tarkan,

bei den meißten RTOS gibt es 2 Klassen von Funktionen, Welche aus 
Interrupts aufgerufen werden dürfen und andere die nicht in einem 
Interrupt aufgerufen werden dürfen. Hast du geprüft das dein 
Interrupthandler nur die Funktionen, die aus interrupts aufgerufen 
werden dürfen, aufruft. Bei FreeRTOS heißen die dann "fromISR" bei CTL 
kann ich dir das nicht sagen.

MfG

Tec

[Matze T. (gruetzwurschd)]

Hi Tec, :P

laut dem Datenblatt darf man bei CTL eigentlich nur keine funtionen in 
ISR's verwenden, die blockieren können.

Daher hab ich extra die funktion genommen:

ctl_message_queue_post_nb( &RxQueue_RawData, MyPointer );

nb = steht hier für no block

Ich glaub es muss was anderes sein!


Kann es sein dass man irgendwie dem RTOS beim Starten mittteilen muss, 
welche ISR's es gibt oder sowas?

[Alex E. (tecnologic)]

Nicht welche es gibt aber bei einem CM3 durchaus welche Prioritäten RTOS 
Funktionen nutzen. Bei FreeRTOS kannst du angeben das von Prio 255 - ka 
15 alle ISRs OS-Fkts benutzen dürfen und ISRs mit Prio <15 dürfen keine 
mehr verwenden und werden nicht vom OS beeinflusst. Die Schwelle 15 
kannst du bei FreeRTOS einstellen, bei CTL weiß ich das nicht.

Ich hab mal in der Doku nachgesehen von CTL dagibt es keine 
Interruptlevel

der Zählt halt nur n ISR count hoch on enter und runter on exit bei nem 
ISR
Vllt liegt da das Problem. Nesten deine Interrupts? vllt ist das eine 
race contition, das mehrere Interupts gleichzeitig triggern und er 
durcheinander kommt. Wie schnell kommen die ISRs hintereinander? USB ist 
ja nicht lahm. ST empfiehlt sogar im USB Rx Interupt keine Queues zu 
bedienen sonder einen FiFo zu nehmen, weil die Queue den Speed bremsen 
soll, ich hab das in zusammenhang mit FreeRTOS mal irgend wo gelesen.
kann mich aber auch irren.


MfG

Tec

[Matze T. (gruetzwurschd)]

Also ich habe mal auch im Rowley-Supportforum gepostet und zur antwort 
bekommen dass die ISR's die funktionen nutzen "priority of the interrupt 
handler is in the lowest half of the priority range".
Hab somit mal die prio auf 16 gesetzt.

Ich hab auserdem die festellung gemacht dass das problem dann auftritt 
wenn ich zwischen diesen beiden codezeilen den new operator aufrufe.

  ctl_enter_isr(); 

  unsigned char* MyPointer;

  MyPointer = new unsigned char[67];

  ctl_exit_isr();

Tec Nologic schrieb:
> Wie schnell kommen die ISRs hintereinander? USB ist
> ja nicht lahm. ST empfiehlt sogar im USB Rx Interupt keine Queues zu
> bedienen sonder einen FiFo zu nehmen, weil die Queue den Speed bremsen
> soll, ich hab das in zusammenhang mit FreeRTOS mal irgend wo gelesen.

Ich hab die framegeschwindigkeit auf 1ms gesetzt. somit denke ich dass 
jede ms diese USB_ISR aufgerufen wird(was mir jetzt nicht übermäßig 
schnell vorkommt).
aber ich hatte auch schon dran gedacht, anstatt der queue wieder nen 
richtig performanten, selbstgebackenen fifo zu benutzen. dann hab ich es 
wenigestens wieder selber in der hand.

[Alex E. (tecnologic)]

Naja new ist so eine Sache. Ich gehe davon aus das das Projekt in Cpp 
geschrieben ist. Musst du dann die ISRs nicht in extern "C" einschlagen?

Andere Sache wie ist new implementiert? mit malloc? oder original von 
Cpp?

Wenn du den originalen von Cpp nimmst wundert mich dein Problem nicht.

Such mal nach New auf dem µC für STM32 gibts da bsps für die neu 
Implementierung von new und delete, da soll es öfter Probleme geben.

Ich habe bisher immer Objekte statisch definiert also global dann wird 
new nicht bemüht.


Dann war meine Interrupt Prio Vermutung garnicht so schlecht.


MfG

Tec

[Matze T. (gruetzwurschd)]

Ich denke ich werde das jetzt mit nem Statischen buffer lösen.

Nachdem ich im supportforum mittlerweile auch einige antworten erhalten 
habe, kam heraus, dass der operator new im hintergrund auf die 
ctl_events_wait funktion zugreift und somit "im verborgenen" doch eine 
wartefunktion des RTOS aufgerufen wird :)

naja jetzt weiß ich zumindest schonmal dass ich das irgendwie anders 
lösen muss :)