osDelay (vTaskDelay) Fonksiyonu Hakkında...

[Tagli]

Ben HSM'ye hiç girmeden basit bir şekilde FSM yapmaya çalışıyorum. Event Queue'ları (kuyruk?) ise global yaptım, sistemdeki öncelik sayısı kadar kuyruk var. Yani Miro Samek'in kullandığı terim ile, her Active Object için ayrı kuyruk kullanmadım (o öyle yapmış galiba). RAM kullanımı kuyruk boyutu ile doğrudan ilgili. Tek ve minimum boyutlu bir kuyruk ile PIC16'da 90 byte ile de blinky yapmak mümkün ama pek işlevsel ve gerçekçi bir uygulama olmayacaktır bu.

Miro Samek event'ler için dinamik bir sistem düşünmüş. Memory pool gibi, sabit bir yapıdan yer ayırıyor, işi bitince de siliyor. Başta bundan kaçınmak istedim, ama sanırım ben de benzer bir yapıya mecbur kalacağım. Çünkü farklı event'lerin verilerini de kuyruğa eklemeye çalışmak kuyrukları gereksiz yere şişirebilir. Önceden RAM'e yerleştirilmiş static event'ler de bazı durumlarda yetersiz kalabiliyor.

Bu arada ana konuyu da çok dağıttık ama laf lafı açıyor...

[quarko]

Benim sistemde de boyutu belli bir queue mevcut. Boyutu mcu kapasitesine ve yapılacak işlerin çokluğuna göre belirliyorum. Duruma göre birden fazla queue da olabiliyor tabi. İlk ayarlamalar yapıldıktan sonra sonsuz döngü içerisinde sürekli queue kontrol edilerek işlenecek mesaj varsa alıp ilgili task a gönderiyor. Her task ın ayrı gövde fonksiyonu ve alabileceği mesajlara ilişkin switch-case kontrolü var. Queue ya gönderilen mesajların her birisinde hedef task, ilgili mesaj bilgisi ve mesaj datası içeriyor. Mesaj datası her zaman dolu olmadığı için çoğu zaman NULL oluyor. Örneğin butona basılma durumu interrupt larla tespit edilip, main task a butona basıldı mesajı iletiliyor. Data olarak ta, hangi butona basıldığının bilgisi gönderiliyor. Dolayısıyla tüm sistem eventler vasıtasıyla işliyor. FSM ler, yazılımsal timer lar, interruptlar hep birlikte güzelce çalışıyorlar. Aslında yapı cooperative bir yapı olduğundan mutex, semaphore gibi kavramlara da ihtiyaç kalmıyor.