STM32 MUTEX Semaphore

Nachtrag:

Anderst Formuliert: Ich möchte eine sporadische Verbindungskontrolle 
durchführen.

Ich habe meinen Code gegenüber dem Beispiel abgeändert und auf den 
Rückgabewert des os_mut_wait geprüft.

Ich habe beobachtet kurz nach dem Einschalten funktionierts, aber 
plötzlich empfängt A nichts mehr.

A ist meine Testeinheit und B ist das eigentliche 
Produkt(EC-Motorensteuerung).

Ich habe für die MUTEX Funktionen extra unabhängige Task aufgesetzt, 
damit der CAN-Task verschont bleibt. Aber trotzdem verstopft irgendwie 
der CAN-Bus!?


Danke und Gruss!

M.B.

hier noch die Prio der Tasks:

1

  otid_bkgnd       = os_tsk_self();

2

  otid_GUI         = os_tsk_create_user (tsk_GUI, 100,&StkTsk, sizeof(StkTsk));

3

  otid_CAN         = os_tsk_create (task_CAN, 60);

4

  otid_functions   = os_tsk_create (task_functions, 50);

5

  otid_mutex2      = os_tsk_create (task_mutex2, 75);

6

  otid_mutex1      = os_tsk_create (task_mutex1, 70);

Deadlock ...

JA aber das wait wird doch wieder released, dann sind die Tasks wieder 
frei...

Es gibt RTOS-Kernels, in denen eine Task eine bereits besitzende Mutex 
erneut anfordern darf, ohne dass eine Blockade auftritt (interner 
Zähler). Und solche, bei denen das nicht zulässig ist, sondern direkt in 
den Deadlock führt. Zu welcher Gattung dieses gehört weiss ich nicht.

Hier: reset_CAN_connection holt sich die Mutex und ruft in diesem 
Zustand request_CAN_connection auf - das sich aber auch erst die Mutex 
holt. Sinn ergibt das wenig, weil direkt rqstConnection aufgerufen 
werden könnte.

Vielen Dank...

Dann ist aber das Example von Keil eher unbrauchbar...

Wie ich schon schrieb: Ich kenne Keil nicht, das war eine eher 
allgemeine Aussage zu RTOS-Kernels. Das Beispiel - habs jetzt erst 
gelesen - legt allerdings nahe, dass es bei Keil zulässig ist.

Danke!

Ich denke, das Example ist eben sehr allgemein. Ich muss noch paar 
Überlegungen investieren.

Der reset darf nur erfolgen wenn der request den Mutex freigegeben hat.

Anderes Thema: Es ist nicht sonderlich sauber, in einer Task eine 
Semaphore zu initialisieren, die in einer konkurrierenden Task ebenfalls 
verwendet wird. Das mag hier zwar aufgrund der Reihenfolge und der Prios 
kein Problem sein, es bleibt aber unsauber und fehlerträchtig.

Task-übergreifende Resourcen sollten initialisiert werden, bevor diese 
Tasks in Verlegenheit kommen könnten, sich drum zu streiten. Also hier 
sinnvollerweise bevor die Tasks überhaupt existieren.

Ja, das steht so ebenfalls im Keil Beispiel, aber das machts auch nicht 
besser.

gehe mit dir einig! Danke für den Hinweis!

Quellcode vom ARTX: 
http://read.pudn.com/downloads92/sourcecode/embed/359226/Kernel/AR_Mutex.c__.htm

Wenn eine Task die Mutex bereits besitzt, dann wird in os_mut_wait nicht 
blockiert, sondern inkrementiert. os_mut_release gibt passend dazu erst 
beim letzten Aufruf wieder frei. Das ist also sauber und entspricht dem 
Beispiel in der Referenz (siehe Link im 1. Beitrag).

Wenn os_mut_release auf eine nicht im Besitz befindliche Mutex 
aufgerufen wird, geschieht nichts. Besser wäre natürlich trotzdem
  if(os_mut_wait (&mutex1, 0xFFFE) != OS_R_TMO)
    {
      rqstConnection();
      os_mut_release (&mutex1);
  }

NB: os_mut_wait ist etwas unschön konzipiert. Im erfolgreichen Fall gibt 
es zwei verschiedene Return-Codes (mit/ohne Wait), im Fehlerfall aber 
nur einen, und der betrifft einen speziellen Fall (Timeout) und heisst 
auch entsprechend.

Folglich wird natürlich wie oben auf den speziellen Fehler getestet, 
nicht auf den Erfolg. So ist es per Design quasi unmöglich, diesem API 
irgendwann einen weiteren speziellen Error-Return hinzu zu fügen, ohne 
haufenweise existierenden Code zu schrotten.