RTOS nedir ?

[vsalma]

Peki bir projeyi tasklara nasıl bölüyorsunuz?

Mesela LCD taskı, seri port taskı, hesaplama taskı gibi mi düşünüyorsunuz yoksa ne nasıl parçalıyorsunuz?

Tek işlemciye projeyi kodlar gibi tek bir taska da uzun uzun kod yazıyormusunuz?

Çevresel birimlerle haberleşme taskı. Hesaplama taskı, hesaplamaya göre output taskı. Sistem test taskı, Logging taskı vs vs. Sistem durumunu göstergeye yansıtma taskı.

kişisel projelerde ~10 civarı task oluyor. Taskların özelliğine göre kimi 5 satır oluyor. Kimi 1000 satır. Haberleştirme ve senkronizasyon işleri için os un kendi fonksiyonlarını kullanıyorum. İşleri çok rahatlatıyor.

İçerisinde bekleme olan işlemlerim varsa onun için genellikle ayrı task oluşturuyorum. örn gsm ile haberleşilecek. Veya flash a yazma okuma silme işi var. Silmede 10 sn bekliyorsun flashı onun için başka bir task kullanıyorum.     


 

[z]

@vsalma

Bu konuda oldukça tecrübeli görünüyorsun. Bu konularda konuşmaya istekli üye sayısı da nerede ise hiç yok.

https://www.picproje.org/index.php/topic,35654.0.html başlığında karalama tarzında bir çekirdek çalışmam var ancak tıkandım.

Çünkü multitasking yapacak alt yapıyı kurarsam, tasklar da aralarında konuşur hale gelirse RTOS elde ederim diye düşünüyordum.

Fakat kazı ayağı öyle değilmiş. Bu konuda beni nasıl yönlendirebilirsin?

Mutex, semaphore gibi konulara neden ihtiyaç duyuluyor kodlarda bunları nasıl kullanıyoruz, bir tasktan bir diğer taska timer haricinde nasıl geçiş yapılıyor örneklerle izah edebilirmisin?

[controller]

yukarıdaki bombayı rtos olmadan patlatmamaya çalışırsak ne yapmamız lazım...?

Yukarıdaki sistemde zaten rtos yok, os da yok. Sadece "real time" konusuna değinildi.

İşletim sistemleri real time olabilir veya olmayabilir.

[vsalma]

@vsalma

Bu konuda oldukça tecrübeli görünüyorsun. Bu konularda konuşmaya istekli üye sayısı da nerede ise hiç yok.

https://www.picproje.org/index.php/topic,35654.0.html başlığında karalama tarzında bir çekirdek çalışmam var ancak tıkandım.

Çünkü multitasking yapacak alt yapıyı kurarsam, tasklar da aralarında konuşur hale gelirse RTOS elde ederim diye düşünüyordum.

Fakat kazı ayağı öyle değilmiş. Bu konuda beni nasıl yönlendirebilirsin?

Mutex, semaphore gibi konulara neden ihtiyaç duyuluyor kodlarda bunları nasıl kullanıyoruz, bir tasktan bir diğer taska timer haricinde nasıl geçiş yapılıyor örneklerle izah edebilirmisin?

Est. Ben rtos u kullanıcı düzeyinde biliyorum . Ama bildiğim kadarıyla altyapısı çok karmaşık değil. Programming Embedded Systems in c and C++ (Michael Barr) isminde bir kitap var. Bu kitapta chapter 8 de os u anlatıyor. Ve basit bir os örneği yazmış. C++ ile yazıldığından okunabilirliği ve anlaması çok kolay. Çok basit ama temel işlevlerin hepsi olan bir os var. Ona bakın isterseniz uzun bir chapter değil.

Bir tasktan diğer taska scheduler geçiş yaptırıyor. Bu scheduler timer la çağrıldığı gibi, semefor bekle, mutex bekle mutex oluştur, event oluştur, sleep gibi osun fonksiyonlarını kullandığınızda da devreye giriyor. Siz semaphore post dediniz bu fonksiyon çağrısında otomatikmen   scheduler çağrılıyor eğer post ettiğiniz semaphoru bekleyen bir task varsa görevi ona veriyor. Aynı şekilde siz taskı bekletiyorsunuz.  Sleep komutunu verdiniz  scheduler çağrılıyor otomatikmen bir sonraki taska görev veriliyor.

[emrahmrcn]

İşletim sistemi temelleri, Tanenbaum,Andrew-Operating.Systems.Design.and.Implementation,2ndEd ile öğrenilir Linus Torvaldsın hocası dır aynı zamanda. Minix i yazmıştır, hoca dediğinde böyle olur. Öğrencileri öğrensin diye işletim sistemi yazmıştır,basit bir OS un temelini içeren bir işletim sistemidir.
Fakat bu bilgileri hazmetmek için uygulamak gerekir ki Linus de dersde gördüklerini evde uygulamış minix in daha iyisini yazmak için(Linux).

Örneğin ben bu kitapları karıştırdım ama sindiremedim, uygulamak gerekiyor. Bunalmış ın sorular çok güzel. İyiki yazılımcı değil, donanımcı. Led örnekleri çok iyi anlaşılır basit.

Mutex, semaphore bildiğim kadarı ile, süreçler arası iletişim için kullanılmakta.
Diyelim ki bir I/O iki farklı süreç kullanacak ama hangisi, I/O bilgisi hangi süreç için geçerli
yada bellek alanında bir yere veri yazılırken, yazan süreç askıya alındığında diğer sürecin bu bellek alanına yazma
hakkı varmı ...

[vsalma]

if (bayrak_kapildi == 0)
{
    .bayrak_kapildi = 1; //bayrağı 1. task kaptı. Ona göre iş yapılacak
    .

Şimdi yukarıda verdiğim örnekte bu değişken volatile olsa bile yukarıdaki mesajımda anlattığım sıkıntı oluşabilir. Bahsettiğim olay değişkenin volatile olup olması değil. Volatile değişkeni compiler optimize ederken bu değişkenin kendi kendine veya başka bir süreç tarafından değişebileceğini hesaba katar ona göre optimizasyona tabi tutmaz.

Ör:

a = 1;
if(a == 0)
{
.
.
.
}

gibi bir kodda if bloğu ölü kod olarak compiler tarafından kaldırılabilir. a yı volatile tanımlarsak a nın başka bir süreç tarafından veya  çevresel  etkiyle (ör  input pini) değişebileceğini bildiririz. Compiler bu nedenle if bloğunu dead code olarak kabul etmez. Öyle bırakır ordaki işlemleri yapar.

Flag kullanılarak yapılan çoğu senkronizasyon işi race conditiona sebep olur. Ve nadiren başgösterecek zor bulunanan hatalara sebep olurlar. Bu nedenle bu amaçla mutex, semephore, vb kullanılır. Hangi hataya sebep olduğunu yukarıda verdiğim örnekte açıklamıştım. Bu mutexin gerekliliğini gösteren bir örnek. Yok alt seviyeye girerseniz kodunuzda timer vs interuptları disable edersiniz, değişkeninizle işinizi yaparsınız sonjra tekrar açarsınız. Bu priority önceliklerini delmenize sebep olabilir. Çok kritik bir işi (ör gelen bir ext interrupt) kaçırabilirsiniz flag işi yapıcam diye.    + kodunuzun bakımı zorlaşır. Gözünüzden kaçan deadlocklara sebep olabilirsiniz.

Mutex,Semaphore,mailbox,event, lock gibi yapılar gerçekten gerekli olduğu durumlarda kullanılmalı, kullanımı abartılmamalıdır.  Gözden kaçan deadlock lara sebep olabilir. En iyi ihtimalle priority inversionlara sebep olabilir. Dikkatli ve iyi analiz ederek kullanılmalıdır.   
   

[z]

Sadece bu bayrak_kapildi kismini okumak ve ardindan set yada reset etmek icin, oncelikle int disable, ardindan bayrak_kapildi degiskenini set yada reset etsek daha sonra da int enable yapsak sorun olmaz herhalde.

[mufitsozen]

Mutex,Semaphore,mailbox,event, lock gibi yapılar gerçekten gerekli olduğu durumlarda kullanılmalı, kullanımı abartılmamalıdır.  Gözden kaçan deadlock lara sebep olabilir. En iyi ihtimalle priority inversionlara sebep olabilir. Dikkatli ve iyi analiz ederek kullanılmalıdır.   

mutex, semaphore vs abartip abartmadigimizi nasil anlariz? 

Gozden kacmayan deadlocklar nasil/niye yapilir?. Ben hep deadlock istenmeyen bir durum oldugu icin bilerek deadlock yapilmaz diye dusunmustum.


Bu "priority inversion" kotu birsey o zaman. buna sebep olundugunda ne gibi kotulukler olusur? Mars Pathfinder'da "priority inversion" kapatildigi icin hata olmustu diye hatirliyorum, ama "priority inversion" acik olup, kullanilinca ne gibi hatalar olur bilemedim.

[vsalma]

Eğer bu flag tasklar arasındaki senkronizasyonu sağlıyorsa tüm interuptları kapatmaya neden gerek var. O sırada external çok önemli bir interrupt kaçabilir. Bir rtos taki öncelik sırası genellikle şöyle oluyor.

Hardware Int > Software Int > Task > Periodik fonksiyonlar.

O flag e bakarken sadece task değişimini kapatmamız lazım. Buda eğer Preemptive bir rtos kullanıyorsak bu flagle alakalı olmayan önceliği kritik bir taskı bekletmeye sebep olur.

Bunun için biz bu değişkeni mutex yaparızki sadece bu değişkenle alakalı tasklar bir birini bölmesin. Biri kapmışsa diğeri beklesin. Mutex serbest kalana kadar.

1. süreç
----------------
Mutex_pend(bayrak_serbest)     //eğer bayrak_serbest 1 ise 0 yap(bu işlem atomik)   değilse burda bekle
.
.
.
Mutex_post(bayrak_serbest) //bayrak_serbest 1 yap


2.süreç
----------------
Mutex_pend(bayrak_serbest)  //eğer bayrak_serbest 1 ise 0 yap(bu işlem atomik)   değilse burda bekle
.
.
.
Mutex_post(bayrak_alindi)  //bayrak_serbest 1 yap


hiç bir zaman iki süreç birbirini kesmez. Flag te bahsettiğim sıkıntı oluşmaz. Harici interupt kaçırılmaz. Bu flagle alakası olmayan yüksek öncelikli task kaçırılmaz.

[vsalma]

mutex, semaphore vs abartip abartmadigimizi nasil anlariz? 

Gozden kacmayan deadlocklar nasil/niye yapilir?. Ben hep deadlock istenmeyen bir durum oldugu icin bilerek deadlock yapilmaz diye dusunmustum.


Bu "priority inversion" kotu birsey o zaman. buna sebep olundugunda ne gibi kotulukler olusur? Mars Pathfinder'da "priority inversion" kapatildigi icin hata olmustu diye hatirliyorum, ama "priority inversion" acik olup, kullanilinca ne gibi hatalar olur bilemedim.

Gözden kaçan deadlocklar oluşabilir demiştim. Bazı deadlocklar geliştirme sırasında farkedilip düzeltilebilir. Bazı deadlocklar ise nadiren oluşuyor olabilir. Testte düzgün çalışır ancak beklenmeyen bir anda sistem kilitlenebilir. Bunun kasdetmişmiştim. Her bir mutex kullanımı düzgünce düşünülmelidir gerçekten ihtiyacım var mı. Eğer gerçekten varsa dikkatlice kullanılmalıdır.  Activity diagramlar ile akış incelenmesi riskli durumları daha rahat görmemize yardımcı olabilir.

Priority inversion aslen daha düşük öncelikli bir taskın kullanılan mutex,semaphore gibi yapılar sebebiyle yüksek öncelikli taskı bastırması anlamına gelir. Eğer düşük öncelikli task yüksek öncelikli taskı bağlıyorsa onun yüksek önceliğinin bir anlamı kalmaz. Bazı gelişmiş rtoslarda priority inheritence bu durumun önüne geçer. Düşük öncelikli taske geçici olarak yüksek öncelik verir.   Pathfinder olayını sadece preemtive rtos kullanılmış bir hata oluşmuş seviyesinde biliyorum. Detaylarını bilmiyorum. Bu konuda priority inheritence kavramı ile priority inversion kavramını karıştırıyor olabilirsiniz.

[mufitsozen]

  Pathfinder olayını sadece preemtive rtos kullanılmış bir hata oluşmuş seviyesinde biliyorum. Detaylarını bilmiyorum. Bu konuda priority inheritence kavramı ile priority inversion kavramını karıştırıyor olabilirsiniz.

Sayin @vsalma, haddim olmayarak, bildigim kadari ile kavramlari karistiran maalesef sizsiniz.  Asagidaki linkten priority inversion kapatilinca ne gibi problemler olusur, daha detayli gorebilirsiniz.

http://research.microsoft.com/en-us/um/people/mbj/mars_pathfinder/mars_pathfinder.html

Sayin @bunalmis, yukaridaki linkteki aciklamalara Mars Pathfinder aracini JPLde yapan ekipten birinin teknik olarak daha detayli bir aciklamasini http://research.microsoft.com/en-us/um/people/mbj/mars_pathfinder/Authoritative_Account.html den okuyabilirsiniz. Bu size gercek bir uygulamada hw ve sw komponentlerin kullanimi RTOS ile yapilan isler hakkindada daha detayli bir fikir verebilir.

[z]

@Vsalma

Bahsettiğim int kapatıp flag set etme yada reset etme işlemi sadece bir kaç makine kodu ile gerçekleşen bir işlem, int kapatıldıktan sonra en geç bir iki cycle sonra tekrar açılacağı için sorun olmaması gerekir. Bu zamana denk gelecek Ext interruptlar zaten donanımsal flaglarını set ettiklerinden int açılır açılmaz işleme alınacaklardır.

Fakat bu jitteri olumsuz etkileyecek bir durum olması lazım.

[vsalma]

Sayin @vsalma, haddim olmayarak, bildigim kadari ile kavramlari karistiran maalesef sizsiniz.  Asagidaki linkten priority inversion kapatilinca ne gibi problemler olusur, daha detayli gorebilirsiniz.

http://research.microsoft.com/en-us/um/people/mbj/mars_pathfinder/mars_pathfinder.html

Sayin @bunalmis, yukaridaki linkteki aciklamalara Mars Pathfinder aracini JPLde yapan ekipten birinin teknik olarak daha detayli bir aciklamasini http://research.microsoft.com/en-us/um/people/mbj/mars_pathfinder/Authoritative_Account.html den okuyabilirsiniz. Bu size gercek bir uygulamada hw ve sw komponentlerin kullanimi RTOS ile yapilan isler hakkindada daha detayli bir fikir verebilir.

Finally, the engineer's initial analysis that "the data bus task executes very frequently and is time-critical -- we shouldn't spend the extra time in it to perform priority inheritance" was exactly wrong. It is precisely in such time critical and important situations where correctness is essential, even at some additional performance cost.

Bu yazıdan benim anladığım priority inheritence kapatılınca neler olduğu. priority inversion kapatilinca değil.  (priority inversion oluşmuş zaten engellenebilse bi sıkıntı olmayacaktı)

... VxWorks mutex object accepts a boolean parameter that indicates whether priority inheritance should be performed by the mutex. ...
... changed the values of these variables from FALSE to TRUE. No more system resets occurred. ...


Burada priority inheritence kullanılmamış. Bu sebeple priority inversion oluşmuş bir senaryo anlatılıyor.

Hala yanlış anlıyorsam lütfen bana link vermeyin şurayı yanlış anlıyorsun karıştırdığın şu diyin.

http://en.wikipedia.org/wiki/Priority_inversion
http://en.wikipedia.org/wiki/Priority_inheritance

[vsalma]

@Vsalma

Bahsettiğim int kapatıp flag set etme yada reset etme işlemi sadece bir kaç makine kodu ile gerçekleşen bir işlem, int kapatıldıktan sonra en geç bir iki cycle sonra tekrar açılacağı için sorun olmaması gerekir. Bu zamana denk gelecek Ext interruptlar zaten donanımsal flaglarını set ettiklerinden int açılır açılmaz işleme alınacaklardır.

Fakat bu jitteri olumsuz etkileyecek bir durum olması lazım.

Yani bu flagler çok sayıda olabilir. Bu arada spi vs gibi hızlı iletişim kanalları kullanılıyor olabilir. Bilmiyorum gerek var mı interruptları kapatmaya. Bence sadece bir interrupt interruptı durdurabilmesi lazım. Çünkü bu çakışma case i çok karşılaşılabilecek bir durum değil aslında. Tabi mutex kullanmanında bir costu olacak bilmiyorum. mufitsozen in paylaştığı makalede Pathfinderda priority inheritence costundan kaçılıp priority inversion oluşmuş. Watchdog timerda bu iş neden bu kadar zamandır yapılamadı diye sistemi resetlemiş durmadan.    (yanlış anlamadıysam)

[z]

Sözkonusu flagları int kapatıp açmadan da set ve reset edecek özel cpu komutları varlığını öğrendim. Aslında bu komutları çok daha önceden öğrenmiştim fakat bu tip işler için kullanılacağını daha bugün anladım.

Merak edenler için LDREX, STREX ve CLREX.

Spin atma diye bir tabir var. Bu siz RTOS kullananlara tanıdık bir ifademi?