osDelay (vTaskDelay) Fonksiyonu Hakkında...

Başlatan quarko, 25 Ekim 2021, 17:42:48

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.
"Aslanlar kendi hikayelerini yazmadıkça, avcıların kahramanlık hikayelerini dinlemek zorundayız."

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.
"Aslanlar kendi hikayelerini yazmadıkça, avcıların kahramanlık hikayelerini dinlemek zorundayız."

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.
Gökçe Tağlıoğlu

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.
"Aslanlar kendi hikayelerini yazmadıkça, avcıların kahramanlık hikayelerini dinlemek zorundayız."

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ı.
Gökçe Tağlıoğlu

quarko

#8
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..
"Aslanlar kendi hikayelerini yazmadıkça, avcıların kahramanlık hikayelerini dinlemek zorundayız."

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.
Gökçe Tağlıoğlu

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.
"Aslanlar kendi hikayelerini yazmadıkça, avcıların kahramanlık hikayelerini dinlemek zorundayız."

MrDarK

Task notify yapısı da alternatif olarak kullanılabilir.
Picproje Eğitim Gönüllüleri ~ MrDarK

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).
Gökçe Tağlıoğlu

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.