osDelay (vTaskDelay) Fonksiyonu Hakkında...

[quarko]

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.

[ahmet35]

Böyle durumlar için semaphore kullanımı daha uygun olur.

[quarko]

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.

[Tagli]

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.

[Erol YILMAZ]

Timer'a START verip, END olmuş mu diye sorgularken,
Diğer olayı da kontrol edebilirsiniz.

[hasankara]

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.

[quarko]

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.

[Tagli]

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ı.

[quarko]

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..

[Tagli]

@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.

[quarko]

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.

[MrDarK]

Task notify yapısı da alternatif olarak kullanılabilir.

[kantirici]

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.

[Tagli]

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).

[kantirici]

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.