Daha önce RTOS suz olarak yaptığım bir gömülü sistem yazılımını FreeRTOS la yapmaya çalışıyorum.
osDelay(vTaskDelay) fonksiyonu ile task içinde beklerken, başka bir olay olduğunda bu beklemeyi iptal ettirip taskı nasıl devam ettirebilirim. Bunun bir yolu var mıdır acaba.
Böyle durumlar için semaphore kullanımı daha uygun olur.
Aslında başka bir olay bahsettiğim olaydan gelen bilgi semaphore dan gelecek. Ama eğer bilgi gelmezse periyodik olarak task işini yapsın, diğer taraftan semaphore gelirse de bir sonraki aşamaya geçsin gibi istiyorum aslında.
Beklemeyi vTaskDelay ile değil de freertos un yazılımsal timer larıyla yapmaya çalışıyorum. Belki bu şekilde bir yolunu bulabilirim.
Event tabanlı bir mantıkla yapılabilir. Söz konusu task'ın bir event queue'su olsun. Bir timer buna periyodik olarak time-tick (veya adı ne olursa) event'i atsın. Semafor yerine de o task yine aynı queue'ya bir başka event atsın. Yani tek bir event queue iki olay için paylaşılsın.
Timer'a START verip, END olmuş mu diye sorgularken,
Diğer olayı da kontrol edebilirsiniz.
SemaphoreHandle_t my_sem= xSemaphoreCreateBinary();
func_task1(){
int delay_time = 100;
while(1){
xSemaphoreTake(my_sem,delay_time/ portTICK_RATE_MS);
}
}
diğer task den "xSemaphoreGive(my_sem);" give ettiğin zaman while döngüsüne devam eder. veya delay time dolduğunda da devam eder.
TaskDelay kullanmak yerine, State machine kurup, periodic timer ile normal çalışma durumunu sağladım. Event in gerçekleştiği yerde de durum değiştirip task içerisinde yapılması gerekeni yaptırdım.
RTOS mantığı ile yazılım tasarlamak başka bir bakış açısı gerektiriyor. Sağladığı avantajlarla birlikte zorlukları da var. Gerekmiyorsa, RTOS a pek girmemek lazım gibi sanki.
Event based tasarlamak da çok farklı. Ama RTOS kullanarak da üzerine event based bir yapı kurulabilir.
Ben henüz tam anlamıyla event based bir sisteme geçemedim. Benim projeler biraz ortaya karışık oldu...
Miro Samek'in Beyond RTOS videolarına bir bakmanızı öneririm. Epey ufuk açıcı.
Aslında ben kendi oluşturduğum queue tabanlı event driven bir sistem kullanıyorum. Preemptive bir yapı yok. Yazılımda herşey mesajlarla ilerliyor. Aslında sürekli queue ya atılan eventler (mesajlar) işleniyor. Yıllardır ara ara rtos lu bir yapıya geçmek istiyorum. Deniyorum da. Ama bir türlü rtos konusunda, ikna olamıyorum. Tam hakimiyet sağlanmadığından, içim rahat rahat yazılım tasarlayamamak beni rahatsız ediyor..
@quarko , aslında senin bahsettiğin sistem Miro Samek'in sistemine çok benziyor, hatta belki aynı. Adam bu yaklaşımın klasik RTOS'tan çok daha faydalı olduğunu söylüyor. Uzun vadede ben de aynı sisteme geçmeyi düşünüyorum. Ancak farklı bir düşünce şekli gerektiriyor, o yüzden mevcut bir projeyi bu sisteme taşımak pek mümkün değil.
Miro Samek'in sistemi, preemptive bir RTOS üzerinde ve onun bazı araçlarını kullanarak da çalıştırılabilir. Ancak bence altta RTOS olmamasının da kendine göre avantajları var. RTOS olunca her task'in kendi stack'inin olması gerekiyor ve bu durum düşük RAM'li işlemciler için sorun olabilir.
Evet, Miro Samek bence haklı gibi görünüyor. Klasik RTOS, tamam birçok avantaja sahip. Ama her sistem üzerinde değil. O yüzden her kapasite seviyesinde sistemlerde, en optimum çözüm queue tabanlı bir event driven sistem gibi görünüyor. Bu sistem basit bir şekilde RTOS lu bir altyapıya da çalıştırılabilir, haklısın.
Task notify yapısı da alternatif olarak kullanılabilir.
Event Driven bir yapıda zaten delay kullanmamak/kullanmıyor olmak gerekiyor. Eğer bir yerde bir bekleme durumu var ise, bekleme durumunun bitmesi bir event oluyor ve bu event ile state değiştirmek gerekiyor.
Ayrıca Qp freamwork(Miro Samek) RTOS ve RTOS olmadan çalışabiliyor.
Bugünlerde PIC18 üzerinde Qp'ye benzeyen ama çok daha basitleştirilmiş bir framework oluşturmaya çalışıyorum. Aslında her türlü işlemcide çalışabilecek kadar basit olacak ama ROM ve özellikle RAM ihtiyacı/kullanımı, çok küçük işlemcilerde kullanılmasını engelleyecek gibi gözüküyor. Basit bir blinky için 200 byte RAM ve 1.5 kB ROM gerekecek gibi (çok kabaca).
Bir ara Qp ye benzer hiyerarşik state machine yazdım. Aslında core denilen kısım çok fazla yer kaplamıyor. Event queue'nun nasıl olacağı kısmı sıkıntılı, genel geçer bir yapı yapmak yada her kaynağa göre burayı modifiye etmek gerekiyor. Ama HSM'yi kaynak kısıtlı bir mcu'da koşturmak pekte iyi olmuyor her state kaynak tüketecektir.
Birde Qp gibi bir örnek olunca ister istemez onu referans alıp orada yapılanları sizde yapmak istiyoruz. HSM yerine FSM(finite state machine) olunca zaten işler çok basitleşiyor. Ama fsm'de kompleks sistemler için yetersiz kalıyor. Örneğin GSM modül ile AT komutları ile konuşurken çok fazla state oluyor ve HSM gerçekten çok kolaylaştırıyor işleri.
Nispeten kaynak bol bir mcu ile çalıştıktan sonra PIC16-18 serisi gerçekten can sıkıyor.
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...
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.