Evet RTOS nedir Ne Avantaj Sağlar ?
Alıntı yapılan: gerbay - 12 Ocak 2011, 22:04:50
gülerek, eğlenerek okuyacağınız bir link;
http://emrahcom.blogspot.com/2009/04/gercek-zamanl-real-time-sistem-nedir.html
s.a. usta
ilk defa bir blok yazısını satır satır okudum, emrah ustayı tebrik ediyorum. hatta bu konuyuda hiç kimse bu kadar anlaşılır anlatamazdı
yemek pişirmeyi öğrendim ama rtos u öğrenemedim ;D
bende çok merak ediyorum bu olayı fakat henüz ne işe yaradığı hakkında kafama yatan bişey olmadı.anladığım tek olay multi tasking.
biri örneklese süper olur
bu noktada hazır bir RTOS mu kullanmalı yoksa kendi RTOS umuzu mu yazmalı?
şimdi rtos u işlemciye yükledikten sonra ki freertos u kullandığımız düşünüyoruz herhangi bir uygulamayı nasıl yükleyip çalıştıracağız ? yada bu uygulamaları ?
(basitten gidiyorum belki anlamsız sorular soruyorum kusra kalmayın)
Bakıyorum Elimde Olan NXP LPC1768 i ve code-red ideyi doğrudan destekliyormuş :)
RTOS nedir sorusuna verilecek en guzel cevap bu olmali.
https://www.picproje.org/index.php/topic,32955.msg230787/topicseen.html#msg230787
http://www.pic24.ru/doku.php/en/osa/articles/pk2_osa_piano
RTOS'un en önemli avantajlarından birisi de kodun okunabilirliğini artırması...
Burada örnekle anlatmış olayı :
http://www.netburner.com/downloads/embedded_projects/RtosVsInfiniteLoop.pdf
http://blog.feabhas.com/about/
Embedded Systems ile ilgili güzel bir link.
RTOS uygulamalarinda bir taskdan bir baska taska nasil veri aktariyorsunuz? Basit bir kod ornegiyle gosterebilirmisiniz?
Yahu RTOS kullanan onca kisi oldugunu biliyorum. Siz de benim gibi bu isin nasil yapildigini bilmiyor ve birbiriyle hic veri alisverisi yapmayan task kodlari mi yaziyorsunuz da cevap vermiyorsunuz?
Merak ettigim konuyu bir ornekle daha acik yazayim.
1 nolu Task, klavyeden enter basilincaya kadar gelen karakterleri string olusturmak uzere biriktirsin. String hazir olunca da;
2 nolu Task 1 nolu taskdan gelen stringi LCD de yazsin.
Merak ettigim konu,Task1 diyorki, HEY Task2, LCD de gostermen icin stringi ramdaki degiskene yazdim. Degiskenin adresi bu. Alip kullandiginda haber verki yenisi gelirse eskisinin uzerine yazayim, kullanmadiysan bileyim de eskisinin uzerine yazmayayim gibisinden muhabbetleri siz mi kodluyorsunuz yoksa RTOS bu isi kendi mi hallediyor?
Nasil oluyor bu islem?
Bunalmış hocam RTOS bunu nereden bilsin ?
Elbette bu kodları yazan biz :) gerekli durum oluştuğunda diğer TASK'a haber vermek için,
bir semafor u tetikliyoruz.
Bunu bekleyen diğer TASK ta işlemini yapıyor....
if(In_Button_A || In_Button_B || In_Button_C || In_Button_D)
{
SysSignalSemaphore( hSemaShortBuzzer );
timerLast = SysGetTime();
}
void TaskShortBuzzer(){
while( TRUE ){
Sys_WaitSemaphore( hSemaShortBuzzer, EVENT_NO_TIMEOUT );
DOUT_BUZZER = 1;
Sys_Sleep( 40 ms );
DOUT_BUZZER = 0;
Sys_Yield();
}
}
Bunu her butona basışta kısa bir DIT sesi çıkartmak için kullanmıştım...
Allegro sagolasin.
Kodu elbette biz yazacagiz da asagidaki gibi biz mi kodlayacagiz yoksa RTOS mu bir seyler yapacak diye merakim kabardi ama verdigin kod sayesinde bu isi RTOS'un hallettigini anladim.
if(Flag1==1) // Task2 daha stringle isini bitirmemis
{
}
else // Task2 isini bitirmis oyleyse yeni stringi yazayim
{
}
RTOS konusu kafamda tam sekillenmedi. Sagda solda okudugum yazilarda da kafamdaki sorulara cevap bulamiyorum.
Birden çok TASK ın haberleşmesi için semafor, event vs başka isimde birşeyler kullanıyorlar.
Anladığım kadarı ile bunların sadece adı değişik :)
Bu arada bence RTOS konusunda oldukça sağlam ilerliyorsunuz...
Bu arada ShoftBuzzer fonksiyonunda gördüğümüz,
Sys_WaitSemaphore( hSemaShortBuzzer, EVENT_NO_TIMEOUT );
ve
Sys_Yield();
fonksiyonları çalıştığında görev paylaşımı yapmak üzere cpu tekrar Schedular'a dönüyor....
@Gerbay
Cok yabanci oldugum yeni bir konuyu ogrenirken acaip zorlaniyorum. Kafamda garip garip sorular beliriyor cevaplarini da hazirda bulamayinca hircimlasiyorum.
Bahsettigin anahtar kelime ile arama yaptim fakat anlayabilecegim basitlikte aciklama iceren dokumana ulasamadim. Belki bu cok sayida isimlendirmenin varligindan konu karmasikmis gibi duruyor.
Fakat eminim basite indirgenmis benzetmelerle RTOS'un ic dunyasi en kazma adamin bile anlayacagi hale getirilebilir.
Neyse simdilik sorunumu posta kutusu tabir ettigim bir structure kullanarak cozdum. Bunun RTOS camiasindaki adi ne bilmiyorum.
Asagidaki hikayeyi aynen uygulayacak kodlari ortak bir fonksiyon olarak yazdim. Dileyen task bu fonksiyonu cagirabiliyor.
Veri yollamak isteyen TASK, ortak kullanilan posta kutusunda Alici TASK'in rafina bakiyor, raf bos ise mektubunu birakiyor. Doluysa bu adam daha once yollanan mektubunu bile acmamis diyip yeni mektup atmiyor ve zamanini bir sonraki taska hediye hediyor boylece posta yollanmak istenen alici taskin islerini daha cabuk yapip posta kutusunu bosaltmasi icin ona kiyak gecilmis oluyor.
Alici TASK, veriye ihtiyac duydugunda posta kutusuna gidip sevgiliden mektup gelip gelmedigine bakiyor.... Gibi bir senaryo kurdum ve en azindan simdilik isim gecici de olsa cozuldu.
Eger Posta kutusu dolu ise ve gonderici, alicinin posta kutusuna yeni mektup koymasi gerekiyorsa cunku bir an once yazmasi gereken mektuplar varsa alicinin posta kutusunu acmasini beklemek gibi luksu yoksa simdilik getirdigim cozum ise yaramayacak, bunu da ileri de ele alacagim.
Ancak soyle bir durum var.
ARM islemcinin "int latency"si soyle iyi boyle iyi deniyor ama, RTOS'da su da olsun bu da olsun denip cekirdek kodlari sisirildikce RTOS hantallasmaya basliyor ve acikcasi bu durumdan hic hosnut kalmadim.
Bence bu isleri software'de değil de hardware'e yaptirmak lazim.
Tasktan Taska gecis otomatik hardware tarafindan halledilecek, Tasktan taska veri aktarimi gene hardware tarafindan yapilacak vs vs.
Kesinlikle boyle cipler de yapilacaktir. Fakat neden simdiye kadar boyle bir cipler cikartmamislar anlamiyorum.
RTOS için A ve R serisi çekirdeklerde durum belki çözülmüştür birde onlar bakmak lazım. A serisi çekirdekler doğrudan işletim sitemi çalıştırıyor.
Bu şimdilik beni çok ama çok aşıyor.
Aşan bir sey yok. Hazir RTOS kullanirsan isler gercekten kolaylasiyor sadece kullanacagin RTOS'un kitapciginda hangi fonksiyonlar var sadece onlari ogreneceksin.
Ben RTOS'un icine kafayı takdim o yuzden kafam karisik. Aslinda hatam, hazir RTOS'lardan birisini iyi kullanmayi ogrenip ardindan bu RTOS'un benzerini yapmak olmali.
Task senkronizasyonu ne demek oluyor?
Mesela
4 tane task var. Her bir task islemeye basladiginda her biri farkli bir is yapiyor olacak.
1 task digerlerine, hey tasklar isinizi gucunuzu birakin, haydi dedigimde hepiniz birden ledleri yakin diye anlamalimiyim?
Sıralamalı işler vardır bazen,
Şu iş bitmeden ötekine başlanamaz gibi,
Bu işlerin takibi de farklı TASK larda ise diğer TASK ın işini bitirip haber verir,
diğeri devam eder.
Cok basit fakat, oyle bir proje sorusu sorun ki;
RTOSla bu proje yapilmak istendiginde RTOS'un olmazsa olmaz butun ozellikleri kullanilmak istensin.
Sanirim asil soruyu buldum.
RTOS oldugu iddia edilen bir sistemin RTOS olmadigini hangi yazilim parcacigiyla ispatlarsiniz?
Alıntı yapılan: bunalmis - 13 Kasım 2011, 18:32:24
Sanirim asil soruyu buldum.
RTOS oldugu iddia edilen bir sistemin RTOS olmadigini hangi yazilim parcacigiyla ispatlarsiniz?
Görevler arası öncelik sıralaması ile anlayabiliriz mesela...
Ama böyle dersen ben bir şey anlamam ki. RTOS bilmeyen birisine soruyu anlaşılır kılmanız gerekiyor.
Mesela deyin ki bir led var. Bir buton var. Butona basınca led yanacak.... vs vs.
Mutex ve semafor ile ilgili soruya ihtiyacım var.
Öyle bir yazılım sorusu sorunuz ki, eğer ki soruyu çözersem, bak şurda mutex şurda da semafor kullanmışsın diyebilesiniz.
--Task 1
if (bayrak_kapildi == 0)
{
.bayrak_kapildi = 1; //bayrağı 1. task kaptı. Ona göre iş yapılacak
.
.
.
}
--Task 2
if (bayrak_kapildi == 0)
{
.bayrak_kapildi = 1; //bayrağı 2. task kaptı. Ona göre iş yapılacak
.
.
.
}
Ortak bir kaynak olsun. Onu hangi süreç ilk alırsa o kullanacak olsun. Birinci task galib geldi diyelim (bayrak_kapildi == 0) şartı sağlandı. Sonra henüz bayrak_kapildi = 1 yapılamadan context switching oldu. Diğer task devreye girdi. baktı bayrak kapıldı flag i 0. O da kaptı.
Bu durumda(race condition) iki süreçte kaynağı kendisinde zannediyor. Ve bu durum belkide çok ciddi bir hataya sebep olabilir. Buradaki sorun
if (bayrak_kapildi == 0)
.bayrak_kapildi = 1;
işlemlerinin atomik olmaması. Bu işlemleri atomik yapmak için bayrak_kapildi değişkenini atomik olarak tanımlamamız lazım. Bu değişkeni atomik olarak tanımlarız. Eğer bayrak_kapildi sadece 1 veya 0 değerini alıyorsa buna mutex denir. Eğer çok değişken alıyorsa semaphore denir. Burada sadece bir örnek oldu. Başka kullanımlarıda var.
Bilmiyorum sorunuzu anlayabilmiş miyim?
Alıntı yapılan: bunalmis - 14 Kasım 2011, 14:09:25
Ama böyle dersen ben bir şey anlamam ki. RTOS bilmeyen birisine soruyu anlaşılır kılmanız gerekiyor.
Mesela deyin ki bir led var. Bir buton var. Butona basınca led yanacak.... vs vs.
Mutex ve semafor ile ilgili soruya ihtiyacım var.
Öyle bir yazılım sorusu sorunuz ki, eğer ki soruyu çözersem, bak şurda mutex şurda da semafor kullanmışsın diyebilesiniz.
RTOS la yaptığınız her şeyi asm ve işlemciye hakimseniz rtos suz yapabilirsiniz. Örneğin bir kritik sistem yazılımı düşünün 20 kişilik ekip yazıyor olsun. Örneğin bir uçak yazılımı. Görevler arası senkronizasyon ve öncelik yönetimi için yazacağınız kod gerçekten yapılan iş kodunu çok fazla büyütür ve anlaşılmaz kılar. Böyle sistemlerinde testi, bakımı zorlaşır. Modülerliği azalır. Yazılan kodların tekrar kullanılabilirliği azalır. O nedenle rtos ların avantajı var diye düşünüyorum.
Bu mesajı yukarıda yazılanlardan bağımsız olarak "rtos nedir" e cevaben yazıyorum. Öncelikle şunu belirteyim, şimdiye kadar gerçek anlamda rtos kullanmamı gerektirecek bir uygulama olmadı. Bende çoğu kişi gibi birgün kullanmam gerekebilir diye teorik olarak çalışmış birisiyim. Ayrıca hobi olarak işletim sistemi tasarımı ile ilgileniyorum, bu açıdan rtos da diğer işletim sistemleri gibi ilgilendiğim konulardan. Mesajımda yanlış bildiğim konular olabilir, doğrusunu bilen arkadaşlar düzeltmek için uyarabilirler.
Öncelikle "gerçek zamanlı" ne demek ona bakalım. Elimizde aşağıdaki resimde görünen bir sistem olduğunu varsayalım. Bir adet 10 saniye zaman ayarlı bomba, bombanın gerisayacını (10, 9, 8, 7....) resetleyen bir giriş, ve bu girişe bağlı gpio su olan bir mcu.
(http://img191.imageshack.us/img191/6141/bombao.png)
Ben işlemci olarak 16F84 ü seçiyorum. Programıda ccs c ile yazacağım. Amacımız bombayı patlatmamak. Sadece main i yazacağım.
main()
{
while(1)
{
delay_ms(9000);
output_high(GPIO); // RESET
output_low(GPIO);
}
}
Gördüğünüz gibi sistem çok basit. Bombaya ve mcu ya aynı anda enerji verdiğimizi düşünürsek 9 saniye sonra yani bombanın sayacı 1 saniye gösterirken mcu bombanın sayacını resetliyor ve bomba tekrar 10 saniyeden geriye doğru saymaya başlıyor.
Donanımsal bir arıza olmadıkça yukarıdaki sistem sonsuza kadar sorunsuz çalışacak ve bomba hiçbirzaman patlamayacaktır.
İşte yukarıda örneğini verdiğimiz bu sistem "gerçek zamanlı (real time)" bir sistemdir. Yani sistemin akışında kötü sürpriz, kararsızlık veya zaman aşımından dolayı bombanın patlaması mümkün değil. Mcu nun her 9 saniyede bir bombayı resetleyeceği gayet açık ve garantidir.
Bir diğer konuda "real time" ın anlamının sıklıkla kullanılan "çok hızlı" demek olmadığıdır. Buradaki real time dan kasıt zamanlamaların kesin değişmez olmasıdır.
Yani ben yukarıdaki devrede kullandığım 16F84 e 1Mhz kristalde taksam, 100Mhz kristalde taksam mcu yine her 9 saniyede bir bombayı resetleyecektir. Mcu hızı ancak yardımcı (yan) etken olabilir.
Şimdilik bu kadar, zamanım olursa ilerki zamanlarda diğer konulara da değinebilirim.
kücük mclarda yapmak pek mantıklı gelmiyor bana rtos ile yazmak icin insan cok zorlanıyor anck kesin yapılması gereken iş ise rtos örnegin yapay kalp makinası kalbin ritminde bir bozulma olursa nasıl komaya giriyorsak makinada zamanlamalarda 1ms bile saparsa sıkıntı yaratabilir rtos başlı basına bir konu bence
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?
yukarıdaki bombayı rtos olmadan patlatmamaya çalışırsak ne yapmamız lazım...?
Alıntı yapılan: bunalmis - 14 Kasım 2011, 16:17:30
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.
@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 (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?
Alıntı yapılan: elek - 14 Kasım 2011, 16:36:52
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.
Alıntı yapılan: bunalmis - 14 Kasım 2011, 17:22:07
@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 (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.
İş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ı ...
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.
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.
Alıntı yapılan: vsalma - 15 Kasım 2011, 09:36:58
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.
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.
Alıntı yapılan: mufitsozen - 15 Kasım 2011, 10:14:17
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.
Alıntı yapılan: vsalma - 15 Kasım 2011, 10:35:26
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.
@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.
Alıntı yapılan: mufitsozen - 15 Kasım 2011, 10:55:38
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_inversion)
http://en.wikipedia.org/wiki/Priority_inheritance (http://en.wikipedia.org/wiki/Priority_inheritance)
Alıntı yapılan: bunalmis - 15 Kasım 2011, 10:57:28
@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)
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?
Alıntı yapılan: bunalmis - 15 Kasım 2011, 12:59:59
Spin atma diye bir tabir var. Bu siz RTOS kullananlara tanıdık bir ifademi?
sayin @bunalmis eger kasdettiginiz "spinlock" tabiri ise, thread/taski re-schedule edilmesin, yada context-switch edilmesin diye loop icinde bir lock free edilsin diye donup duran loop'lara denir. Thread/task loop'da surekli lock free edilmismi diye baktigindan scheduler acisindan calisiyor gibi gozukur ve rescheduling yada context-switching overhead olmadan (vakit kaybetmeden) calisir. Fakat spinlock kullanilirken spinlockda gececek zamanin cok kucuk olmasi gerekir. Yani beklenen lock'u bekleyen butun threadlar bunu cok cok kisa bir sure icin kullanmalari lazim, yoksa kullanim amacindan cikar.
Evet tam olarak bununla ilgiliydi.
Bir kilit açıkmı değilmi diye bakıp, eğer kilitli ise açılıncaya dek döngü içinde kiliti okuma olayında karşılaştım bu tabirle.
Peki burada sözü edilen kilide RTOS dünyasında özel bir ad veriliyormu?
Çünkü mutex ve semaphore hala benim için birer X.
mutex_pend(&lock)
dedik diyelim. Eğer lock kilitli ise burada takılı kalıyor. Yani bu fonksiyon scheduler ı çağırıyor. Lock un değerini soruyor eğer lock kilitli ise bu süreç devam etmiyor . Bekleme kuyruğuna giriyor. Bir dahaki schedular çağrısında (timer tick le olabilir veya başka bir sistem çağrısıyla olabilir.) kuyrukta bekleyen mutexlere bakılıyor. Açılmışsa bu sürecin devam etmesine izin veriliyor. Yani her bir schedular çağrısında kilit kontrolü yapılıyor.
Alıntı yapılan: vsalma - 15 Kasım 2011, 14:11:04
mutex_pend(&lock)
dedik diyelim. Eğer lock kilitli ise burada takılı kalıyor. Yani bu fonksiyon scheduler ı çağırıyor. Lock un değerini soruyor eğer lock kilitli ise hiç bir işlem yapmıyor. Bekleme kuyruğuna giriyor. Bir dahaki schedular çağrısında (timer tick le olabilir veya başka bir sistem çağrısıyla olabilir.) kuyrukta bekleyenlere bakılıyor. Açılmışsa bu işlemin devam etmesine izin veriliyor. Yani her bir schedular çağrısında kilit kontrolü yapılıyor.
Daha önce zaten yazmışsınız şimdi olaylar ard ardına gelişip şekillenince anladım.
Alıntı Yap
if (bayrak_kapildi == 0)
.bayrak_kapildi = 1;
işlemlerinin atomik olmaması. Bu işlemleri atomik yapmak için bayrak_kapildi değişkenini atomik olarak tanımlamamız lazım. Bu değişkeni atomik olarak tanımlarız. Eğer bayrak_kapildi sadece 1 veya 0 değerini alıyorsa buna mutex denir. Eğer çok değişken alıyorsa semaphore denir. Burada sadece bir örnek oldu. Başka kullanımlarıda var.
Semaphore, konusunu daha önce okumuştum oradaki anlatılanları da bu vesile ile anlamış oldum. Şimdi hem mutexi hem de semaphoru çekirdeğe ekleyebilirim.
Fakat şimdi de aklıma şu soru takıldı.
Ne zaman mutex ne zaman semaphore tercih edilir?
Mutexe binary semaphore da deniyor. sadece 1-0 değerleri alıyorsa flag imizdeki gibi mutex. Ama diyelim 3 sürecin girişine izin veriliyor bir kaynak için sonra gelen bekliyor ise bu semaphore. Semaphore un ilk değerine 3 atanıyor her gelen onu 0 değilse bir azaltıyor. 0 ise bir sürecin onu serbest bırakmasını (arttırmasını) bekliyor. Wikipedia da semaphore için şöyle bir örnek var.
Suppose a library has 10 identical study rooms, intended to be used by one student at a time. To prevent disputes, students must request a room from the front counter if they wish to make use of a study room. When a student has finished using a room, the student must return to the counter and indicate that one room has become free. If no rooms are free, students wait at the counter until someone relinquishes a room.
Kusura bakmayın çok soru soruyorum.
Doğru anladığımdan emin olmak istiyorum.
İki örnek vereceğim.
Birinci örnek fonk1 adındaki fonksiyonu kim kaparsa o çalıştıracak diğerleri ancak fonksiyon boşa çıkınca kapabilecek.
Bunun için fonksiyonun girişine bir mutex koyarım. Kilit açıksa kilitler ve fonksiyonu çalıştırır. Fonksiyonun çıkış noktasında da kilidi açar.
Fonksiyona girildiğinde kilit varsa fonksiyondan çıkar.
Burada fonksiyonu çalıştırıp çalıştırmamak hala kodun inisiyatifindedir. Fakat kilit varsa buna rağmen fonksiyonu koşturursa sistem sapıtır.
Olay böylemidir? Yoksa Kilit varsa task otomatik olarak Run durumundan Ready durumuna mı alınır?
Bir diğer örneğim de
Bir değişkenimiz var. Bu değişkeni tasklar istediği gibi değiştirebiliyor. Bu değişkenle işi olan task bir kilide bakıyor. Kilitli ise değişkene ellemiyor yada task Ready konumuna geçiyor.
Kilit açıksa kilitliyor değişkeni değiştiriyor işi bitince kilidi açıyor.
Alıntı yapılan: bunalmis - 15 Kasım 2011, 15:08:43
Kusura bakmayın çok soru soruyorum.
Doğru anladığımdan emin olmak istiyorum.
İki örnek vereceğim.
Birinci örnek fonk1 adındaki fonksiyonu kim kaparsa o çalıştıracak diğerleri ancak fonksiyon boşa çıkınca kapabilecek.
Bunun için fonksiyonun girişine bir mutex koyarım. Kilit açıksa kilitler ve fonksiyonu çalıştırır. Fonksiyonun çıkış noktasında da kilidi açar.
Fonksiyona girildiğinde kilit varsa fonksiyondan çıkar.
Burada fonksiyonu çalıştırıp çalıştırmamak hala kodun inisiyatifindedir. Fakat kilit varsa buna rağmen fonksiyonu koşturursa sistem sapıtır.
Olay böylemidir? Yoksa Kilit varsa task otomatik olarak Run durumundan Ready durumuna mı alınır?
Bir diğer örneğim de
Bir değişkenimiz var. Bu değişkeni tasklar istediği gibi değiştirebiliyor. Bu değişkenle işi olan task bir kilide bakıyor. Kilitli ise değişkene ellemiyor yada task Ready konumuna geçiyor.
Kilit açıksa kilitliyor değişkeni değiştiriyor işi bitince kilidi açıyor.
Est. 1. örnek için Kilit varsa task otomatik olarak Run durumundan Suspended durumuna alınır. Yani orada bekler. (Ne kadar bekleyeceği eğer açılmazsa devam edebileceği de var gelişmiş sistemlerde)
2. örnekte de geliyor kilitli ise askıda kalıyor. Taskın biri askıda kaldı diyelim. Kilidi almış task ta askıda kalıp 3. bir taskı bekliyorsa 1. mecburen 3. yü de beklemiş olur.
1. task ikinciyi bekliyor. 2. task ta 3. bekliyor 3. task ta 1. yi bekliyorsa :) deadlock oluşur.
Peki mutex ve semaphore özelliğini de çekirdek kodlara eklediğimizi varsayalım.
Çekirdeğe çizelgeleme işlemini de (scheduling) eklersek, artık RTOS yazdık diyebilirmiyiz yoksa eklenmesi gereken daha çok şey mi var?
@vsalma deadlock deyince daha önce okuduğum bir problem geldi aklıma.
Alıntı YapYuvarlak masa cevresinde oturan n>2 sayıda filozof vardır. Bu filozoflar ya makarna yerler ya da düsünürler. Makarna yemek icin 2 catal gerekir ve her iki filozof arasında 1 catal vardir. Şimdi efendim bu filozoflardan hepsi once sag taraflarındaki catalı alırlarsa ne olur, hicbiri yemek yiyemez, e ellerinde catal olunca düsünemezler de kalırlar oyle. ama mesela egitirsin filozofu, belki diger catal yerinde yoksa eline aldıgını bırakır, ama ya hepsi eline aldıgı catalı bırakırsa? o zaman yine yiyemezler dallamalar. hepsinin sırayla tıkınıp düsündükleri bi masada deadlock olmaz, livelock da olmaz.
ekşisözlükten alıntı. "dining philosophers problem" olarak geçiyor. Sanırım task iletişimi için güzel bir örnek.
Evet öyleymiş. Teşekkürler
Windows 95,xp,vista vs.... real time mı?
Bu kapıştırma işini nasıl yapıyorsun?
iki tane flip flop devresi yapsam,çıkışlarına led... biryerlerden tetiklenip aynı anda yanıp sönse...real time oluyor...
pic in a1 ve a2 çıkışına iki led bağlasam,"sözde aynı anda" yanıp sönse, bu real time olmaz...
Alıntı yapılan: elek - 15 Kasım 2011, 20:38:50
iki tane flip flop devresi yapsam,çıkışlarına led... biryerlerden tetiklenip aynı anda yanıp sönse...real time oluyor...
pic in a1 ve a2 çıkışına iki led bağlasam,"sözde aynı anda" yanıp sönse, bu real time olmaz...
neden? eger butun sistem bu kadarsa bence olur!
Alıntı yapılan: gerbay - 15 Kasım 2011, 20:23:30
hassas ölçümleri GPIO pinlerini farklı osiloskop kanallarına bağlayıp pulse layarak osiloskop üzerinden yapıyorum..
VxWorks ile FreeRTOS'uda bir denermisin (Hatta birde RTEMS ile. RTEMS'i ciddi merak ediyorum)? Sonuclarida bir tablo ile verebilirmisin?
Alıntı yapılan: gerbay - 15 Kasım 2011, 21:27:54
müfit bey o setup ı bozalı çok oluyor ama VxWorks ile FreeRTOS karşılaştırması biraz abes olur.. wv pasat ile polo yu kıyaslamak gibi olur.. VxWorks ile Integrity falan daha kıyaslanabilir şeyler ama ben o testleri yaparken VxWorks e lisans parası ödemeden halledebilirmiyiz diye araştırıyordum..
dediginde haklisin ama interrupt latency farki %20mi %200mu? RTEMSde baslangicta hard-real-time diye ve ticari bir proje olarak baslamisti, sonradan GPL oldu. Benim bilmek istedigim, VxWorks gibi pahali bir cozum yerine kabul edilebilir bir performansi olan bedava bir cozum.
Neyse setup'i bozduysan yapacak birsey yok, firsat olurda bir stajyer filan bulursam bir denerim.
Alıntı yapılan: mufitsozen - 15 Kasım 2011, 21:05:51
neden? eger butun sistem bu kadarsa bence olur!
rtos u anlamaya çalışıyorum...
verdiğim örnek yanlış mı...
Bir task bir diger taski fonksiyon cagirir gibi cagirabilirmi?
Cagirabilirse;
Tasklar timer denetiminde sira ile cagrilirken birde fonksiyon cagirir gibi birbirlerini cagirmaya kalkarlarsa tasklardan bazilarinin hic calisamama (sira gelmeme) gibi bir durumu olusturulabilirmi?
öyle hissediyorum ki rtos u algoritmaların içinde aramak boşuna...
rtos ya pazarlama taktiği yada bir bütünü oluşturan bağımsız çalışan devreler...
yani çok eski bir şey....mesela zil tesisatı... ;D
amatör uğraş olarak çok kanallı dimmer asm programı yazmıştım
tam hatırlamıyorum ama 1000 civarında satır vardı sanırım..
sonra picbasic e geçtim...
Alıntı yapılan: gerbay - 15 Kasım 2011, 23:12:39
task zaten sanal bir kavram ve task a bir giriş noktası olarak bir metod veriyorsunuz zaten (task entry point). Eğer metodunuzda sonsuz döngü yoksa gayet rahat olarak bir task başka task ın "giriş metodu" nu çağırabilir.
benzer şekilde aynı task giriş metodu üzerine birden fazla task da başlatabilirsiniz. bunlar gayet normal şeyler. mesela "thread pool" diye bişii var ki pool da ki task lar (thread ler) aynı task entry point üzerine başlatılır..
Sorumun devami icin ne soylenebilir?
Alıntı Yap....fonksiyon cagirir gibi birbirlerini cagirmaya kalkarlarsa tasklardan bazilarinin hic calisamama (sira gelmeme) gibi bir durumu olusturulabilirmi?
konuyu bilmiyorum....
hala anlamaya çalışıyorum...
zil tesisatını onun için örnek verdim...
cevap için sağolun....
işin içinde yazılımda var, donanımda..
işe özel yazılım ve donanım oluyor bu rtos...
pc ve programlar bazen çalışmıyor,reset atılıyor, silip tekrar yükleniyor,bir sürü itiş kakış oluyor..... donanımda birşey yok...
sonra çalışıyor...
bütün bunlar rtos olmadığı için yani...
rtos da güvenilir olan yazılım, neden pc de veya windowsda güvenilir değil...?
Alıntı yapılan: gerbay - 16 Kasım 2011, 00:39:10
windoze böyle tasarlanmış bir OS değil..
tasarlanamaz mı? ya da neden tasarlanmıyor...
tamam okuyacağım...
Threadlerin durumlarinin, Run, Ready ve Blocked olarak isimlendirildigini varsayalim.
Thread1 Run durumunda iken, VarA değişkenini Mutex ile koruma altına almış olsun.
Daha işlemi tamamlanmadan Ready konumuna dussun, Thread2 ise Run konumuna gecmis olsun.
Thread2 VarA degiskenine ulasmak istediginde
Bu degiskenin kilit durumunu gosteren, KilitVarA flagini kontrol eden RTOS fonksiyonu cagirir.
Eger VarA kilitli ise RTOS'un mutex fonksiyonu, Thread2 yi otomatik olarak Blocked pozisyonuna iteler. (Yoksa Blocked degil de Ready pozisyonuna mi duser?)
Bu olay anladigim gibi mi cereyan eder?
Thread2 VarA degiskenine ulasmak istediginde bu degiskenin kilitli olup olmadigini test etmeden dogrudan VarA ya ulasmak isterse
sistemin cuvallamasina neden oluruz.
Dogru mu anlamisim?
Programi biz yazacagimiza gore neleri kilit altina aliyorsak, bunlari kullanacak yazilim parcalarinin her birinde bu kontrolu yapacak fonksiyonu cagirmak bizim sorumlulugumuzdadir. Dogrumudur?
Aşağıdaki sorunun cevabı hayati derecede önemli.
Bir degişkeni mutex ile kilit altina almış olalım.
Kilidi açmadikca diğer threadler değişkene ulaşamayacaklardır.
Kilidi açma yetkisi kilidi vuran threadde midir? RTOS buna garantor olmaktamıdır?
Yoksa kıllık yapmak istesek diger bir thread kilidi açmak istese açabilirmi?
Alıntı yapılan: bunalmis - 16 Kasım 2011, 13:54:44
Aşağıdaki sorunun cevabı hayati derecede önemli.
Bir degişkeni mutex ile kilit altina almış olalım.
Kilidi açmadikca diğer threadler değişkene ulaşamayacaklardır.
Kilidi açma yetkisi kilidi vuran threadde midir? RTOS buna garantor olmaktamıdır?
Yoksa kıllık yapmak istesek diger bir thread kilidi açmak istese açabilirmi?
killik yapmaya gerek yok, programi yazan sizsiniz. Degiskene ulasmak icin mutex'i beklemek zorunda degilsiniz. Beklemezsiniz, degiskenin degeri yanlis olur, programinizdaki hatayi bulmak icin saclarinizi yolarsiniz. Biz profesyoneller buna "bug" diyoruz :-) .
Secim sizin.
Alıntı Yap...Eger VarA kilitli ise RTOS'un mutex fonksiyonu, Thread2 yi otomatik olarak Blocked pozisyonuna iteler. (Yoksa Blocked değil de Ready pozisyonuna mi duser?)
Bir parçasını alıntı yaptığım Bir üstteki soruma nasıl cevap veririz?
@Mufitozen hocam.
Elbetteki programı yazan biziz ve bahsettiğim durumda programın sapıtacagı kesin. Kendi çekirdeğini yazmak isteyen neyi impelent edecek neyi etmeyecek belirsiz. RTOS, kilit açma yetkisini sadece kilit vurana vermişse bunu da çekirdeğe implement etmemiz lazım.
Alıntı yapılan: bunalmis - 16 Kasım 2011, 14:24:45
Bir parçasını alıntı yaptığım Bir üstteki soruma nasıl cevap veririz?
@Mufitozen hocam.
Elbetteki programı yazan biziz ve bahsettiğim durumda programın sapıtacagı kesin. Kendi çekirdeğini yazmak isteyen neyi impelent edecek neyi etmeyecek belirsiz. RTOS, kilit açma yetkisini sadece kilit vurana vermişse bunu da çekirdeğe implement etmemiz lazım.
Evet, sizinde bahsettiginiz gibi RTOS bunu kontrol edip, bu kontrol mekanizmalarinin tasklar arasinda dogru senkronizasyonu saglamasi lazim. Bundanda daha ileri olarak eger bir deadlock durumu olmus ise, tasklar hep birbirlerini bekliyorlarsa , onuda bir sekilde anlayip, hata vermeli, bunun kaydini tutmali, sistemi ya restart yada reboot ederek baslatmali yani hata durumundan gracefully cikabilmeli. Cunki sistem basinda kimse olmadanda kendi basina calismaya devam edebilmeli, hatalar olussa bile. Ornegin benim tecrubeli oldugum telekom sistemlerinde bir santralin hic durmadan 20 sene calismasi beklenir. 1 sene boyunca sistemin tamamen hizmet disi kalma suresi 15 dakikayi gecemez. Buna sisteme yeni yazilim yuklenmesi, updateler vb dahildir. (%99.9999 uptime) Herhangi bir trunk hatti eger 10 dakikadan uzun bir muddet hizmet disi kalirsa FCC yazili ve sozlu savunma ister ve genellikle eger mazeretinize inanirsa ve sansiniz varsa 60-100 bin usd bir ceza ile bir daha yapma der. vs. Tabiiki tibbi, askeri sistemler, havacilikta kullanilan sistemler, otomotiv sanayinde kullanilan sistemlerinde bu tip gereksinimleri vardir. Yoksa urununuze satis hakki, yada kullanim lisansi verilmez.
Alıntı yapılan: gerbay - 16 Kasım 2011, 17:12:23
deadlock vs durumlarda sistemin otomatik olarak restart edilmesi vs. çok yanlış olur bence ki öyle yapan bir sistem de var mı bilmiyorum. Onun yerine isteyen watchdog kurup restart edebilir zaten.. bir de sistemde atıyorum 100 task olsun, belki çok önemli olmayan 4-5 task deadlock olacak.. bu durumda diğer tasklar çalışmaya devam edebilirler..
boyle bir suru sistem var, vede kullanimda. Ama seninde dediginde kismen dogru, bu tip error recovery actionlarin vacgecilmez parcalarindan biride watchdog timer routinedir. Tasklarin hepsinin yada calismasi gereken bir kumenin deadlocka girdigini sadece watchdogdan anlamak cok zordur, cunki diyelim 10 task var, 3u deadlocka girmis, diger 7side event bekliyor ve belkide saatlerce schedule edilmeleri gerekmiyecek. Bu arada sistem idle loopta, yada OS icinde calisip duruyor. dolayisi ile watchdog aktif olmayabilir, cunki OS zaten hicbirsey schedule edilmedigi icin watchdog timer'i idle loopta kendisi resetliyordur (hatanin farkina varmazsa) buda sistemin donup kaldigi izlemini verir.
Wikipedia'da soyle bir aciklama var:
Alıntı YapOften, neither avoidance nor deadlock prevention may be used. Instead, deadlock detection and process restart are used by employing an algorithm that tracks resource allocation and process states, and rolls back and restarts one or more of the processes in order to remove the deadlock. Detecting a deadlock that has already occurred is easily possible since the resources that each process has locked and/or currently requested are known to the resource scheduler or OS.
ornegin daha once bahsettigim Mars Pathfinder hatasini JPLden bir muhendis soyle aciklamis:
Alıntı Yap
The failure was identified by the spacecraft as a failure of the bc_dist task to complete its execution before the bc_sched task started. The reaction to this by the spacecraft was to reset the computer. This reset reinitializes all of the hardware and software. It also terminates the execution of the current ground commanded activities. No science or engineering data is lost that has already been collected (the data in RAM is recovered so long as power is not lost). However, the remainder of the activities for that day were not accomplished until the next day.
The failure turned out to be a case of priority inversion (how we discovered this and how we fixed it are covered later). The higher priority bc_dist task was blocked by the much lower priority ASI/MET task that was holding a shared resource. The ASI/MET task had acquired this resource and then been preempted by several of the medium priority tasks. When the bc_sched task was activated, to setup the transactions for the next 1553 bus cycle, it detected that the bc_dist task had not completed its execution. The resource that caused this problem was a mutual exclusion semaphore used within the select() mechanism to control access to the list of file descriptors that the select() mechanism was to wait on.
The select mechanism creates a mutual exclusion semaphore to protect the "wait list" of file descriptors for those devices which support select. The vxWorks pipe() mechanism is such a device and the IPC mechanism we used is based on using pipes. The ASI/MET task had called select, which had called pipeIoctl(), which had called selNodeAdd(), which was in the process of giving the mutex semaphore. The ASI/ MET task was preempted and semGive() was not completed. Several medium priority tasks ran until the bc_dist task was activated. The bc_dist task attempted to send the newest ASI/MET data via the IPC mechanism which called pipeWrite(). pipeWrite() blocked, taking the mutex semaphore. More of the medium priority tasks ran, still not allowing the ASI/MET task to run, until the bc_sched task was awakened. At that point, the bc_sched task determined that the bc_dist task had not completed its cycle (a hard deadline in the system) and declared the error that initiated the reset.
Alıntı yapılan: gerbay - 16 Kasım 2011, 18:45:27
hata direk priority inversion kaynaklı ve yazılımcı hatası..
zaten pathfinder ın da işletim sistemi olan VxWorks de bu durumu önlemek için mutex create ederken uygun parametreler var, eski sürümlerde de var;
mutexHandle = semMCreate(SEM_Q_PRIORITY | SEM_INVERSION_SAFE);
diyerek mutex semaphore oluşturmaları gerekiyordu ama aslında problem yazılımcı hatası.. Eğer mutex i yukardaki parametreler ile oluştursaydı bu durumda deadlock ın önüne geçmek için düşük priority li taskın kritik bölgede priority si yükseltilecekti ve bu şekilde deadlock a girilmeyecekti..
yani şu linkte anlatılan özellik kullanılarak bu durum önlenecekti;
http://en.wikipedia.org/wiki/Priority_inheritance
sonuçta olay yazılımcı hatası..
hayir degil, cunku sistem calismaya devam ediyor, bilgi kaybetmiyor. hatayi bulana kadar da bazi gunler verilen komutlari yerine getirmesede sistem calismaya ve haberlesmeye devam ediyor. Yoksa hem hatanin troubleshoot edilmesi hemde duzeltilebilmesi mumkun olamazdi.
Restart/reboot ederek sistemin hatadan en az zararla cikip tekrar operasyonel olmasini sagliyorsun. Hata durmunun neden kaynaklandigi, root cause vs baska birsey. Dusunku boyle birsey ucakta oldu, birkac sn restart/reboot ediyor ve sistem yine operasyonel oluyor.
Marstaki cihaz bu hata durumunda bile dunya ile irtibatini kaybetmiyor, bilgi alip veriyor vede yeniden duzeltilmis programi veya corrective patch yuklenebiliyor. Buda sistemin error condition'i anlayip restart etmesi ile mumkun!
Alıntı yapılan: gerbay - 16 Kasım 2011, 19:15:40
ya programcı aynı hatayı dünya ile iletişim yapılıp kodu alıp yükleyen kısımda yapmış olsaydı?
gerçi o durumda da rebootdan sonra belki aynı duruma düşmezdi..
watchdog ile yapmak bana daha uygun gibi geliyor
O zaman sende JPLde xalisip uzaya giden robotlar filan programlama! ;)
;D
Saka bir yana bir cok kritik sistemde zaten reliability icin redundant birimler kullanilir ve bunlar active/standby yada active-active pairler halinde calisir. Dolayisi ile bir hata durumunda restart/reboot yapilirken bile digeri hemen oburunun islerini alir ve deam eder. Yoksa 3-5milyon LOC olan bir telefon santralinda senede 15 dakika downtime nasil yaparsin!
Bircok kereler printerdan error mesaji cikmasa sistemin active-standby switchover ettigini vs anlamazsin bile.
yani demem oki watchdog RTOS ile led yak, butona bas daha karisik ne olabilirki gibi bir arguman. Cok buyuk cok karisik sistemlerde hatadan cikmak, servisi her zaman saglamak icin cok karisik error handling mekanizmalari kurmak lazim. Pathfinderdada dikkat edersen error handler restart etti diyor. Yani bir cok subsistem var, ve bunlar dogru islem icin durmadan sagi solu kontrol ediyorlar. Haa, active/standby yada active-active pairler birbirileri ile durmadan heartbeat sinyalleri degis dokus ederek zaten bir cesit karisik watchdog mekanizmasi yapiyor ama, o bu konunun disinda
sanırım anladım..
RTOS bir programlama tekniği, donanım ile alakası yok...
Şurda güzel birşeyler yapmış vatandaş;
http://www.youtube.com/watch?v=E2uuzLN3QbA&feature=related
Interrupt geldigini ve bunun kabul edildigini, interrupt rutininde Ornegin ADC den okunan degerin bir degiskene aktarilacagini varsayalim.
Fakat bu degisken daha onceki tasklardan birisi tarafindan kilitlenmis olsun.
Boyle bir durumda ne olur? RTOS'larin bir cozumu varmidir?
Olaylarin bu sekilde gelismesi kullanicinin programi yanlis bir mantikla yazmis olmasindan mi kaynaklanir?
Alıntı yapılan: bunalmis - 17 Kasım 2011, 15:02:22
Interrupt geldigini ve bunun kabul edildigini, interrupt rutininde Ornegin ADC den okunan degerin bir degiskene aktarilacagini varsayalim.
Fakat bu degisken daha onceki tasklardan birisi tarafindan kilitlenmis olsun.
Boyle bir durumda ne olur? RTOS'larin bir cozumu varmidir?
Olaylarin bu sekilde gelismesi kullanicinin programi yanlis bir mantikla yazmis olmasindan mi kaynaklanir?
@bunalmis hocam, normalde interrupt handler ile alinan degerler asenkrondur. Dolayisi ile baska bir taskin onu bloke etmesi yanlis bir tasarim olur. dogrusu, degere erismek isteyenler degerin alinip alinmadigini bir semaphore yada mutex ile bekler. ISR deger gelince bunu mutex yada semaphore arayicilig ile taska bildirir. Yani bloke olan tasktir. Eger gelen deger cok sik ise, ve boyle basit bir mekanizma ile bilgi aktarimi saglanamiyorsa bir queue, mailbox vb mekanizma ile ISR degerleri FIFO Q'ya push eder, task(ler)de gelen degerleri pop eder. Boylece asenkron bir eventi/degeri tasklar ile senkron yapabilirsiniz.
http://www.mentor.com/resources/techpubs/upload/mentorpaper_69305.pdf
İşe yarar bir dökümana benziyor.
Erol Şimşek...
Adaşımı dinleyin lütfen ! :)
(http://www.embedded-news.tv/images/stories/isystem_logo.png)
http://www.embedded-news.tv/component/resource/article/6-featured/289-isystemsimsek-1 (http://www.embedded-news.tv/component/resource/article/6-featured/289-isystemsimsek-1)
http://www.embedded-news.tv/component/resource/article/6-featured/289-isystemsimsek-2 (http://www.embedded-news.tv/component/resource/article/6-featured/289-isystemsimsek-2)
En yüksek öncelikli taskımız aşağıdaki gibi ve çalışıyor olsun.
void Task1()
{
}
Önceliği düşük diğer tasklar geçmişte bir şekilde çalışmış, yarıda kalmış, bir olayları başlatmış vs olsun.
Yukarıdaki çalışan yüksek öncelikli taskın işletimi yarıda kesilip, daha düşük öncelikli taskların çalışması mümkünmüdür?
Sistem preemptive ise, yüksek öncelikli task mutex beklemeye sleep e vs girmediyse yaptığı iş kesilmez. Interruptlar kesebilir tabi.
Kusura bakmayın while içinde yazacaktım unutmuşum. While var varsayarak tekrar ele alırmısınız?
void Task1()
{
while(1);
}
"priority boosting" ile mümkün. round robin öncelik seviyesi aynı tasklar arasında geçiş yapar.
Alıntı yapılan: gerbay - 18 Kasım 2011, 17:39:37
@vsalma hocamın yazdığı gibi eğer preemptive ise sürekli olarak o task çalışır interrupt lar dışında.. eğer round robin ise diğer task lara da geçilir..
Peki preemptive ve round robin den hangisi daha iyidir yada ne zaman hangisi tercih edilir?
Alıntı yapılan: gerbay - 18 Kasım 2011, 18:08:18
RTOS lar preemptive olmalı.. zaten ciddi RTOS lar default olarak preemptive çalışırlar..
sevgili @gerbay, bu tam olarak dogru degil. RTOS kullanirken temel prensip tasklarin tepki zamanlarinin predictable olmasidir. Eger sistem cok karisik degilse (task sayisi az ise, ve zamanlamalardaki kisitlar cok keskin degilse) priorityli round-robinde problem cikartmayabilir.
yani su yada bu metodun iyiligi degil, sistemin uygulamanin kisitlarina uygun olup olmadigi onemli. illa preemptive olacak vs diye gereksiz buyukluk ve komplex bir sistem tasarlamayada gerek yok.
Preemptive calisan sistem neden daha buyuk ve komplex oluyor?
Alıntı yapılan: bunalmis - 18 Kasım 2011, 21:53:06
Preemptive calisan sistem neden daha buyuk ve komplex oluyor?
round-robin calisan bir sistem daha kucuk ve basit oldugu icin.
Einstein'da daha once belirttigi gibi gibi her sey goreceli. ;D
Alıntı yapılan: gerbay - 18 Kasım 2011, 21:56:43
preemptive çalışan sistemler daha büyük ve complex değil.. ticari rtos lara bakın, hepsi default olarak preemptive ayarlı.. VxWorks olsun, Integrity olsun piyasayı elinde tutanlar o şekilde..
tabi round robin enable etme seçeneği de var. Hatta VxWorks kendi yazdığınız scheduler ı da kullanabilecek şekilde tasarlanmış..
ve VxWorks gibi microkernel kullanan RTOSlarda istenmeyen fonksiyonlari vs sisteme dahil etmeden kernelin daha kucuk yada buyuk oldugunu.
Istersen degisik opsiyonlar ile VxWorksun boyutlari nasil degisiyor bir dene.
VxWorks anladigim kadariyla unlu RTOS'lardan (RTOS'@lardan). Peki bu, CM3 islemciler icin kullanilmak istendiginde preemptive calisacak sekilde kurgulandiginda RTOS'un kendisi kac kb yer kapliyor.
VxWorks'un CM3 uygulamalarinda CPU'ya getirdigi yuku, gecis zamanlari, ram rom ihtiyaci gibi bilgileri nasil ogrenebilirim?
Vxworks ve Integrity i öğrenme amaçlı lisans satın almadan ücretsiz şekilde deneyebilir miyim? Bu osları çalıştıracak bilinene boardlara mı bakmalıyım yoksa herhangi SBC a konfigure edilmesi kolay mıdır?
Başka Konu Açmak istemedim.
Android işletim sistemi bir RTOS mudur
evet se nereden biliyoruz ?
hayırsa nereden biliyoruz ?
teşekkür ederim.
Hocam Wx in yanından geçememesi mi sizi bu "Değildir" yargısına ulaştırdı?
Zondroid altında RT-Linux mu var Linux mu
ChibiOS RT hakkında ne düşünürsünüz ?
Gördüğüm kadarı ile ciddi şekilde geliştirilmiş ve dökümantasyonu yapılmış.
http://www.chibios.org/dokuwiki/doku.php?id=start (http://www.chibios.org/dokuwiki/doku.php?id=start)
Alıntı YapEfficient and portable preemptive kernel.
Best in class context switch performance.
Many supported architectures and platforms.
Static architecture, everything is statically allocated at compile time.
Dynamic extensions, dynamic objects are supported by an optional layer built on top of the static core.
Rich set of primitives: threads, virtual timers, semaphores, mutexes, condition variables, messages, mailboxes, event flags, queues.
Support for priority inheritance algorithm on mutexes.
HAL component supporting a variety of abstract device drivers: Port, Serial, ADC, CAN, EXT, GPT, I2C, ICU, MAC, MMC, PWM, RTC, SDC, SPI, UART, USB, USB-CDC.
Support for external components uIP, lwIP, FatFs.
Extensive test suite with benchmarks.
Alıntı yapılan: Allegro - 16 Mart 2012, 21:40:21
ChibiOS RT hakkında ne düşünürsünüz ?
Gördüğüm kadarı ile ciddi şekilde geliştirilmiş ve dökümantasyonu yapılmış.
Ben bir yerde daha rastlamıştım bu RTOS'a. Fakat inceleme şansım olmadı maalesef.
Ama ilk izlenimlerim iyi gibi. Yani en azından dediğiniz gibi dökümantasyonu çok sağlam...
Genellikle örnekler ve anlatım hep açık kaynak IDE ler üzerinden gidiyor ama IAR ve Keil destekleri de var.
STM32F4 Discovery üzerinde bir örneği de var sitede. Bu örneği deneyen oldu mu ?
http://www.chibios.org/dokuwiki/doku.php?id=chibios:articles:stm32f4_discovery (http://www.chibios.org/dokuwiki/doku.php?id=chibios:articles:stm32f4_discovery)
Rtos kullanirken tasklar arasi veri aktarimi icin global değişken kullanıyorum ancak bazı tasklarda sanki bu global değişken hiç değişmiyormuş yada yerel static bir değişkenmiş gibi davranıyor... Tasklar arası veri aktarımı için global değişken uygun değilmidir?
@mcan,
hangi rtos ve derleyici bu?
Alıntı yapılan: Allegro - 17 Mart 2012, 10:16:18
@mcan,
hangi rtos ve derleyici bu?
hocam rtx kullanıyorum derleyici de keil-uv4, yazdığım ilk programda çakıldım probleme denk geldim. Problemi sizin açtığınız başlıkda (Başka bir RTOS: Keil RTX) da yazdım ancak probleme dair bişey bulamadım ayrıca "keil rtx delay problemi" adlı başlıkda da global değişkenlerden kaynaklandığını düşündüğüm başka garip bir olay ile karşılaştım.Global kullanılırmı kullanılmaz mı anlayamadım.Amacım program yazarken cpu nun kullanım yüzdesinin gösteren ufak bir yardımcı program yazmaktı, yazdım çalışıyor fakat bazı durumlarda sapıtıyor mantıksız çalışıyor.
Mantıken verilerin hepsi taşınacak diye birşey yok...
RTX ile pek bir deneyimim olmadı açıkçası...
Problem noktasını iyice yakalamaya çalışırsan çok iyi olur.
Alıntı yapılan: mcan - 17 Mart 2012, 11:51:52
hocam rtx kullanıyorum derleyici de keil-uv4, yazdığım ilk programda çakıldım probleme denk geldim. Problemi sizin açtığınız başlıkda (Başka bir RTOS: Keil RTX) da yazdım ancak probleme dair bişey bulamadım ayrıca "keil rtx delay problemi" adlı başlıkda da global değişkenlerden kaynaklandığını düşündüğüm başka garip bir olay ile karşılaştım.Global kullanılırmı kullanılmaz mı anlayamadım.Amacım program yazarken cpu nun kullanım yüzdesinin gösteren ufak bir yardımcı program yazmaktı, yazdım çalışıyor fakat bazı durumlarda sapıtıyor mantıksız çalışıyor.
Anladigimdan degil ama kafa yormaya calisalim.
Sozkonusu global degiskene ulasan tasklari buraya koyabilirmisin? Bir de bu degiskenin tipinin ne oldugunu bilelim.
Alıntı yapılan: z - 17 Mart 2012, 13:46:02
Anladigimdan değil ama kafa yormaya calisalim.
Sozkonusu global degiskene ulasan tasklari buraya koyabilirmisin? Bir de bu degiskenin tipinin ne oldugunu bilelim.
*---------------------------------------------------------------------------*/
__task void InitTasks (void) {
id2 = os_teşekkür_create (task2, 1);
id1 = os_teşekkür_create(Cycler, 1);
os_tmr_create(100,33);
os_teşekkür_delete_self();
}
/*----------------------------------------------------------------------------
* Cycler: RTX Kernel starts this task with os_teşekkür_create (Cycler, 1)
*---------------------------------------------------------------------------*/
__task void Cycler (void) {
for (;;)
{
temp_cpu_load++;
}
}
/*----------------------------------------------------------------------------
* Task 2: RTX Kernel starts this task with os_teşekkür_create (task2, 1)
*---------------------------------------------------------------------------*/
__task void task2 (void) {
for (;;) {
if(timer_exp==33)
{
temp_cpu_load = 0;
timer_exp=0;
os_tmr_create(100,33);
}
}
}Tasklar bunlar
char timer_exp = 0;
volatile unsigned int temp_cpu_load=5,cpu_load=0;Değişkenler bu şekilde tanımlı.
/*--------------------------- os_tmr_call -----------------------------------*/
void os_tmr_call (U16 info) {
/* This function is called when the user timer has expired. Parameter */
/* 'info' holds the value, defined when the timer was created. */
cpu_load = temp_cpu_load;
temp_cpu_load = ((8727024-cpu_load)/87270);
printf("Cpu Loads =%%%u , %u\r\n",temp_cpu_load,cpu_load);
timer_exp = 33;
/* HERE: include optional user code to be executed on timeout. */
} timer fonksyonu bu şekilde tanımlı.
Program her saniyede bir şu çıktıları sırası ile veriyor
Cpu Loads =%48 , 4497944<CR><LF>
Cpu Loads =%49211 , 8995884<CR><LF>
Cpu Loads =%49160 , 13493824<CR><LF>
Cpu Loads =%49108 , 17991764<CR><LF>
Cpu Loads =%49057 , 22489704<CR><LF>
Yani sayaç olarak kullanılan değişken hiç sıfırlanmıyor .Program her saniyede bir çıktı verdiği için os_timer doğru çalışıyor.
Çıktılardan sadece ilki doğruya yakın onuda rtos düzgün çalışsa kalibre ederim, tasklar aynı öncelikli round robin devrede dolayısıyla işlemcinin %50 vaktinde sayması gerekiyor.Çıktı olarak %48 almışım.
Not: verdiğim kodda teşekkür diye bir kelime yok ancak t s k harfleri yan yana gelince onu teşekküre çeviriyor.
BeRTOS'a da bakmanızda fayda var.Arduino üzerinde de çalışıyor. http://www.halitalptekin.com/link/T (http://www.halitalptekin.com/link/T)
altium tasker ile rtos uygulaması yapan bir yerde örnek gören varmı kardeşler.Bide bu beosda tcp stack destegi varmı
RTOS ile uğraşan arkadaşlara bir sorum var.Şimdi RTOS ile anladığım kadarı ile kodda dakiklik sağlanıp çok daha kısa süren kodlar yazılabiliyor.Şimdi sizden bir tane RTOS kullanarak bir tanede aynı işi yapan normal kod koyabilir misiniz?Birde açıklayarak koyarsanız benim gibi bu konuda bilgisi olmayanlara da yardımcı olur.