Kendimize ait RTOS Yazımı, Multitasking hakkında

[mufitsozen]

Karsi karsiya kaldigim problem (interruptin System Tick ile kesilmesi, System Tick ile Task degistirme asamasinda kesilen interupt rutininde islenmemis kodlarin oylece kalmasi) zaten OS yapisinda bilinen bir problemmis. Neyseki cozumu de var.

Cozum: The Definitive Guide To The ARM CORTEX M3 (Second Edition) Sayfa 128

Bir diger aciklama ise http://embeddedgurus.com/state-space/2011/09/whats-the-state-of-your-cortex/

sayin hocam saygida kusur etmek istemem ama bahsettiginiz problemin cevabi bu son mesajiniz olamaz.

cunki siz (gercekten) cok bilinen RTOS interrupt nesting problemini tarif ediyorsunuz, verdiginiz referans(aciklama) ise yine cok bilinen arm cortex-m serisinde (muhtemelen chip tasarimcisinin esrar/eroin/alkol karisimi bir maddenin etkisi altndayken) yaptigi interrupt tasarimindan olan bir garip durum. Yani genel bir probleme ozel bir aciklama getiriyorsunuz.

RTOS interrupt nesting icin kullanilan cesitli methodlar var, isr nesting counter kullanmak, isr lar icin ozel/tek stack kullanmak, isrdan dondukten sonra scheduleri ancak daha yuksek oncelikli "ready" task varsa yapmak,  isrin tamamini critical section icine almak. isr kodunun onune/sonuna bu teknik(ler)i kullanan prologue/epilogue kod yazmak vb

siz 2011 kasinda bu konuda kaynak arastirmak istemiyorum, hemde hobi olarak yapacagim dediginiz icin daha once bu baslikta mesaj yazmamistim ama goruyorum, sizde bir takim kitaplari okumaya baslamissiniz. onun icin affiniza siginarak bu yorumu yaptim.

[z]

Hocam ne kusur etmesi estagfurullah.

Karsi karsiya oldugum Tick Timer'in yarida kestigi interrupt problemine cozum olarak Cortex islemcide zaten PendSV seklinde bir cozum varmis.
Bu cozumden henuz haberdar oldum ve verdigim linkte PendSV icin kisa bir hatirlatma yapmis ardindan da cortexlerdeki bir bugdan sozetmis.

Su anda, RTOS cekirdegi nedir nasil yaziliri anlatan kitaplari okumak yerine problemleri ele alis felsefem geregi Bulent Tasklari islemciye nasil sirayla kosturur buna nasil cozum getirir seklinde yol katediyorum.

Daha onceleri hic karsilasmadigim bir interrupt sorunu ile karsilasinca interruptlari nasil yonetirim konusunda arastirma yapmaya basladim.

Henuz cozum uretmemis olsam da RTOS yazarlarin karsilastigi problemi kendi kendime kesfetmis oldugum icin acaip mutluyum.

Aslinda siz bir RTOS kursu duzenleseniz hepimiz icin cok iyi olacak.

[mufitsozen]

Aslinda siz bir RTOS kursu duzenleseniz hepimiz icin cok iyi olacak.

Aman hocam sayin Niyazi saralin basina gelenlerden sonra kurs ver sonra mahkemeyle  ugras benim yasimda maddi manevi alinamiyacak kadar buyuk bir risk.
Ama benimde gonlumden bildiklerimi ogrenmek isteyenlere aktarmak geciyor.

Keske mba yapmaktansa doktorami yarida birakmasaydim, universitenin birinde egitmen filan olur, seminerler workshoplar filan yapardim.

[z]

Bu konuyu hortlatmanın zamanı geldi.



En son yukarıdaki gibi bir düzeneği yapmıştım. Sonra ilgilenemedim.

Şimdi tekrar ele alıp kaldığım yerden devam etmek istiyorum.

Aslında oturup en basitinden bir RTOS öğrenip bir kaç kod yazıp ardından bu projeye devam etmem lazım fakat forumdan yardım bekliyorum.

Çalışmamın son halinde 8 taneye kadar task oluşturup her birini sırayla koşturabiliyordum.
Daha da öteye gitmedim.

Tasklar arası veri alışverişinde aşılması gereken sorunlar  olduğunu gördüm  ve bunlarla alakalı olarak Semafor ve Mutex gibi kavramların olduğunu duyduydum.

RTOS kullananları, öncelikle semafor ve mutex konusunda aydınlatılmaları için davet ediyorum.

[yamak]

Hocam Semaphore shared bir bölgeye aynı anda birden fazla taskın erişememesi için kullanılır mesela aşağıdaki örnek üzerinden gidecek olursak,

'Micrium'un sayfasından alıntı'

void  Task1 (void *p_arg)
{
    OS_ERR  err;
    CPU_TS  ts;
  
  
    while (DEF_ON) {
        :
        OSSemPend(&MySem,                              (1)
                  0,                                   (2)
                  OS_OPT_PEND_BLOCKING,                (3)
                  &ts,                                 (4)
                  &err);                               (5)
        switch (err) {
            case OS_ERR_NONE:
                 Access Shared Resource;               (6)
                 OSSemPost(&MySem,                     (7)
                           OS_OPT_POST_1,              (8)
                           &err);                      (9)
                 /* Check "err" */
                 break;
  
            case OS_ERR_PEND_ABORT:
                 /* The pend was aborted by another task     */
                 break;
  
            case OS_ERR_OBJ_DEL:
                 /* The semaphore was deleted                */
                 break;
  
            default:
                 /* Other errors                             */
        }
        :
    }
}

Burda OSSemPend fonksiyonu çağırıldığında eğer bu semaphore u alan başak bir task yoksa OS_ERR_NONE case işletilir ve shared resource a erişilir.İş bitince de semaphore release edilir.Bu şekilde shared resource a aynı anda birden fazla task ın erişmesi engellenir.

Mutex'in kullanımı ve kullanım amacı semaphore a çok benzer fakat mutex priority inversion denen olayın oluşmasını da engeller.Priority inversion ını da bir örnek üzerinden anlatırsak:
Mesela düşük orta ve yüksek önceliğe sahip sırasıyla A,B ve C adında tasklarımız olsun. ilk olarak A taskı çalışssın ve x semaphore unu alsın.Semophore u daha release etmeden de C taskının çalışma zamanı gelmiş olsun C taskı daha yüksek öncelikli olduğu için A taskını preempt eder.C taskı da bir resource a erişmek için yine x semaphore una ihtiyaç duysun tabi x semaphore u A taskında olduğu için scheduler tekrardan A taskına switch eder.Bu sıra da yine A taskı x semaphore u bırakmadan B taskının zamanı gelmiş olmuş doğal olarak B taskının priority si daha yüksek olduğu için yine A taskı preempt edilir.B taskının işi bitir A taskına geri dönülür A taskının da x semaphore u ile işi bittikten sonra C taskına switch edilir ve C taskı işini bitirir,
Şimdi burda ne olmuş oldu:
C taskı en yüksek önceliğe sahip olmasına rağmen B taskı C taskının çalışmasını engellemiş oldu.Bu olaya da priority inversion denir.
İşte semaphore yerine mutex kullanınca şöyle bi olay oluyor.
A taskı x mutex ine sahipken C taskı tarafında preempt edilirse A taskının priority si C taskının priority sine eşitlenir.Bu sayede araya başka task giremez.

[z]

O zaman Semafor için şöyle diyebilirmiyiz?

Global değişkenlerimiz var. Tasklar bunları ortaklaşa kullanacaklar.

Sırası gelen task golabal değişkene bir bakıyor üzerinde rahatsız etmeyin diyor. Task görevi bir sonrakine devrediyor.
Bir sonraki bakıyor yahu bu mesgul levhasını ben koyduydum işimi görüyüm de millette kullansın diyor işini bitirip meşgul levhasını kaldırıyor.

Benzetim tamı tamına doğrumudur?

[yamak]

Aynen hocam.
Bu bahsettigimiz semaphore resource management icin kullanilan semaphore du.
Bir de senkronizasyon amaciyla kullanilan semaphore var.Micrium da tasksemaphore diye geciyor.
Ornegin bir uart ISR imiz olsun.ISR mesgul etmemek icin gelen datalari baska bir task icinde handle etmek isteyelim. Budurumda taskin basinda belli bi semaphore u bekleriz. Gerekli data gelince o semaphore u ISR in icinde release ederiz. Boylece ISR i sadece sadece gelen datalari biriktirmek icin kullaniriz.
Sunu da belirteyi: Resource management icin kullanilan semaphore yeri eger shared data miktari az ise interruplar disable etme metodu da kullanilabilir. Ornegin tek bir instruction i semaphore ya da mutex ile koruma altina almak yerine interruptlari disable daha sonra da enable edebiliriz. Bu islem daha az islem gucu gerekirdiginden boyle durumlarda tercih edilebilir.

[z]

Peki semaphoru doğru anladıysam semaphore kullanarak yapamayacağım işler olabilirmi?

Yani sadece semaphore mekanizması ile proje yapamazmıyız?


Birde pic gibi minik microlar için RTOS benzeri şeyler yazmışlar. Bu bahsettiklerinizin hepsini bu rtoslar yapabiliyormu?

Yani mutex, semaphore, Cooperative Schedule, Round Robbin vs vs...

[Icarus]

Eğer böyle yaparsanız RTOS olmaz.
DOS Multitasker olur

[yamak]

Peki semaphoru doğru anladıysam semaphore kullanarak yapamayacağım işler olabilirmi?

Yani sadece semaphore mekanizması ile proje yapamazmıyız?


Birde pic gibi minik microlar için RTOS benzeri şeyler yazmışlar. Bu bahsettiklerinizin hepsini bu rtoslar yapabiliyormu?

Yani mutex, semaphore, Cooperative Schedule, Round Robbin vs vs...

Hocam kasteddiğiniz işler neler mesela?
Diğer rtos'ları çok bilmiyorum ama freertos fena değildir ve bir çok platformu destekler.

[z]

Her 1 ms de task geçişi yapsam, bir de global takas değişkenlerime semaphore özelliği eklesem elde edeceğim yapı ile şöyle bir proje yapamazsın diyebilirmisin demek istiyorum?

Yani ilave olarak neler neler daha olması lazım?  Acil durumlarda hangi  tasktan hangisine geçileceği sıralamasını  her taskın belirleme şansı da var.

[yamak]

Hocam yapabilirsiniz.
Fakat message queue,event,gibi mekanızmalarla yapmak istediğiniz şeyleri daha kolay bir şekilde gerçekleştirebilirsiniz.Yukarıda da bahsettiğim gibi bazı durumlarda mutex de kullanmanız gerekebilir.Yani bu şekilde peşin konuşmak biraz yanlış olur.Projenin gidişatına göre ancak belli olur neyi kullanıp kullanmayacağınız.

[z]

Kafamı karıştıran konu bu mutexdi scheduleydi bu gibi kavramları koda dökmeye kalktıkça çekirdek büyümeye başlayacak bu da gecikmelere neden olacak.

Acaba RTOS sistemlerde 3..5 mikrosaniye zamandan sayılmayan ihmal edilebilir değerlermi?

[AsHeS]

Kafamı karıştıran konu bu mutexdi scheduleydi bu gibi kavramları koda dökmeye kalktıkça çekirdek büyümeye başlayacak bu da gecikmelere neden olacak.

Acaba RTOS sistemlerde 3..5 mikrosaniye zamandan sayılmayan ihmal edilebilir değerlermi?

http://wiki.chibios.org/dokuwiki/doku.php?id=chibios:metrics
Ölçülebilir olması önemli bu gecikmelerin.