Semaphoren Kurze Erklärung.

[PEte (Gast)]

Hi,
Ich habe gerade so meine Probleme einen Atmel Code zu verstehen. Den 
Multitasking scheduler habe ich mittlerweile fast verstanden.

Jeoch wird nach jedem Task die Funktion Scheduler_call_next_task() 
ausgeführt, der Sinn dahinter ist mir noch nicht klargeworden.

bit   scheduler_tick_flag;
#define Wait_semaphore(a) while(!(a)) (a) = FALSE
#define Scheduler_call_next_task()    Wait_semaphore(scheduler_tick_flag)

         Scheduler_task_1();
         Scheduler_call_next_task();

Was genau treibt diese Semaphore? Aus wiki werde ich auch nicht wirklich 
schlau.

[Uwe .. (uwegw)]

Wo wird scheduler_tick_flag denn mal auf true gesetzt?

[nocheinGast (Gast)]

Es wäre wahrscheinlich leichter zu antworten, wenn du uns den kompletten 
Code zeigen würdest und nicht nur ein paar Zeilen hinklatschst, die 
wahrscheinlich so nicht im Code dastehen...

[PEte (Gast)]

Naja ich habe halt gedacht das die paar Zeilen einfacher zu überblicken 
sind als der gesamte Code der über 20 dateien verstreut ist. Die 
wichtigsten sind im Anhang.

Es handelt sich um das USB Generic HID Beispiel von Atmel

http://www.atmel.com/dyn/resources/prod_documents/AVR328.zip

[Oliver (Gast)]

PEte schrieb:
> Was genau treibt diese Semaphore?

Stichworte zum nachschlagen in deinem C-Buch:

while-Schleife
define-Makro
!-Operator

Oliver

[PEte (Gast)]

Oliver schrieb:
> PEte schrieb:
>> Was genau treibt diese Semaphore?
>
> Stichworte zum nachschlagen in deinem C-Buch:
>
> while-Schleife
> define-Makro
> !-Operator
>
> Oliver

Ja die while schleife wird solange ausgeführt bis a = True (bzw. 
scheduler_tick_flag = True). Aber was soll das?

[Jörg W. (dl8dtl) (Moderator)]

PEte schrieb:
> Aber was soll das?

Interprozess-Synchronisation.

Wobei der zweite Prozess vermutlich ein Interruptkontext ist.  Musst
du halt gucken, wo scheduler_tick_flag noch so benutzt wird (ist
vermutlich durch das wirre Makro-Gewurschtel nicht offensichtlich).

[PEte (Gast)]

Jörg Wunsch schrieb:
> Wobei der zweite Prozess vermutlich ein Interruptkontext ist.  Musst
> du halt gucken, wo scheduler_tick_flag noch so benutzt wird (ist
> vermutlich durch das wirre Makro-Gewurschtel nicht offensichtlich).

Der Witz ist ja das es nirgendwo gesetzt wird?! Ich habe diese sinnlosen 
Funktionen einfach alle mal rausgeworfen und es scheint immer noch zu 
funktionieren. Also die Programmierung dieser Beispiele mit dem 
"Makro-Gewurschtel ©" ist irgendwie ziemlich bescheuert.
Das Problem hat sich damit wohl gelöst.

Vielen Dank :))

[Jörg W. (dl8dtl) (Moderator)]

PEte schrieb:

> Der Witz ist ja das es nirgendwo gesetzt wird?!

Das wiederum halte ich für ein Gerücht.  Wenn es nie gesetzt würde,
würde der Code an dieser Stelle "stehenbleiben".  Macht er aber
wohl nicht.

> Ich habe diese sinnlosen
> Funktionen einfach alle mal rausgeworfen und es scheint immer noch zu
> funktionieren.

"Absense of evidence is no evidence of absence.", fällt mir da nur ein.

Du kannst dir ja angucken, ob du mit LUFA besser zurecht kommst.

[micha (Gast)]

PEte schrieb:
> Der Witz ist ja das es nirgendwo gesetzt wird?!

Schau die mal alle Timer an; mit Sicherheit wird dort das Flag gesetzt, 
ggf. nicht offensichtlich sondern über einen Alias/direkten 
Speicherzugriff

[Oliver (Gast)]

Jörg Wunsch schrieb:
>> Der Witz ist ja das es nirgendwo gesetzt wird?!
>
> Das wiederum halte ich für ein Gerücht.  Wenn es nie gesetzt würde,
> würde der Code an dieser Stelle "stehenbleiben".  Macht er aber
> wohl nicht.

Kann schon sein, mit SCHEDULER_TYPE = SCHEDULER_FREE

#if SCHEDULER_TYPE != SCHEDULER_FREE
//! When SCHEDULER_TYPE != SCHEDULER_FREE, this flag control task calls.
bit   scheduler_tick_flag;
#endif

00185 #ifndef SCHEDULER_TYPE
00186   #error You must define SCHEDULER_TYPE in config.h file
00187 #elif SCHEDULER_TYPE == SCHEDULER_FREE
00188   #define Scheduler_set_tick_flag()
00189   #define Scheduler_reset_tick_flag()
00190 #elif SCHEDULER_TYPE == SCHEDULER_TIMED
00191   #define Scheduler_new_schedule()      Wait_semaphore(scheduler_tick_flag)
00192   #define Scheduler_set_tick_flag()     (scheduler_tick_flag = TRUE)
00193   #define Scheduler_reset_tick_flag()   (scheduler_tick_flag = FALSE)
00194 #elif SCHEDULER_TYPE == SCHEDULER_TASK
00195   #define Scheduler_call_next_task()    Wait_semaphore(scheduler_tick_flag)
00196   #define Scheduler_set_tick_flag()     (scheduler_tick_flag = TRUE)
00197   #define Scheduler_reset_tick_flag()   (scheduler_tick_flag = FALSE)
00198 #elif SCHEDULER_TYPE == SCHEDULER_CUSTOM
00199   #error Make sure you have setup macro/fct Scheduler_new_schedule & Scheduler_call_next_task
00200   #define Scheduler_set_tick_flag()     (scheduler_tick_flag = TRUE)
00201   #define Scheduler_reset_tick_flag()   (scheduler_tick_flag = FALSE)
00202 #endif

Oliver

[Jörg W. (dl8dtl) (Moderator)]

Oliver schrieb:

> Kann schon sein, mit SCHEDULER_TYPE = SCHEDULER_FREE
>
>
>

> #if SCHEDULER_TYPE != SCHEDULER_FREE
> //! When SCHEDULER_TYPE != SCHEDULER_FREE, this flag control task calls.
> bit   scheduler_tick_flag;
> #endif
>

Dann wird der gezeigte Code aber vermutlich bei SCHEDULER_TYPE ==
SCHEDULER_FREE gar nicht erreicht.  Schau dir mal das Ergebnis des
Präprozessors an (Dateiname.i, wenn du --save-temps benutzt, oder
Compileroption -E).

[PEte (Gast)]

Jörg Wunsch schrieb:
> Dann wird der gezeigte Code aber vermutlich bei SCHEDULER_TYPE ==
> SCHEDULER_FREE gar nicht erreicht.  Schau dir mal das Ergebnis des
> Präprozessors an (Dateiname.i, wenn du --save-temps benutzt, oder
> Compileroption -E).

Ja danke für den Tipp bin auch gerade zur selben Zeit drüber gestolpert. 
Aber mal im Ernst, zwei makros inneinander verschachtelt um eine normale 
Funktion aufzurufen das ist doch schon ein bisschen sinnfrei.