SERIN2 ve SERİN Komutlarını Çalıştıramıyorum?

[Bahri Bilir]

Picde usart pibleri var ve bu pinlerle üst kademe ile iletişim kuruluyor.Ve üst kademeden alınan verilerim alt kademeye aktarılması gerekiyor.Ama verileri aynı hatla aktarmak hattı fazla yoğunlaştırdığı için verilerde çakışmaların ve hataların önüne geçemiyorum.Eğer sistem hattın boşluğunu kontrol ederek çalışırsa süre çok fazla uzuyor.Bende çözüm olarak üst kademeden verileri dahili usartla yani hserin komutuyla alıp alt kademeylede serin2 ve serout2 komutuyla farklı bir hat üzerinden haberleşmeyi düşünüyorum.

Ama aşağıdaki kodu kullandığımda döngü koda gelip donuyor."gir" değişkenine tanımlı pine sürekli olarak veri akıyor.Eğer gir değişkeninin tanımlı olduğu pinin veri akışını keser tekrar verirsem döngü 1 tur atıyor ve tekrar komuta gelip kalıyor.

SERIN2 gir,12,10,BASLA,[WAIT ("BLR"),dec5 A]

Aşağıdaki şekilde de denedim sonuç aynı.Tek fark bu sefer gir pininin akışını kessemde döngü komuttan ayrılmıyor.

SERIN2 gir,12[WAIT ("BLR"),dec5 A]

1 gündür bu projede rs232 yi kullanadar iletişimi verimli hale getirmeye çalışıyorum.16f886 ile 4 mhz de 9600 baudda %60 hata alırken yine 4 mhz de 19200 de %30 hata aldım.Açıkcası mantıken yanlış.Belkide programın zamanlamasından kaynaklanan bir durum.Ama şuan 4 mhz de 19200 baudda hserin hserout komutu ile oldukça başarılı veri aktarabiliyorum.Veri hem picler arası başarılı aktarılıyor hemde usb dönüştürücü ile aynı anda başarı ile bilgisayarda takip ediyorum.Yüzde oranları c# yazdığım uygulama ile ölçüldü.

Eğer serin2 kodundaki sıkıntıyı çözemezsem ya 2 usart pinine sahip pice geçneyi düşünüyorum.Yada alt kademeyle i2c veya SPI ile haberleşmeyi.

Serin2 komutunun kullanımı hakkında yardımlarınızı bekliyorum.

[Bahri Bilir]

Bu arada arkadaşlar serin komutunun kullanımı "WAIT ("A"),dec5 A,WAIT ("B"),dec5 B,WAIT ("C"),dec5 C,WAIT ("D"),dec5 D,WAIT ("E")" gibi çoklu olmayıp ETE hocanın dersinden anladığım kadarıylada sadece 1 işaretçi ve bir değişken verisi aktarılabildiğini zannediyorum.Bir kaç deneme yaptım.1 işarretci ve bir değişkenle verileri almaya çalıştığımda programı derlemeyi başardım.Ama 1den fazla işaretçi ve değişken kullanarak yapmaya çalıştığımda derleyici hata veriyor.

[İlyas KAYA]

Serin değil de DEBUG komutunu inceleyin. Ben USART haricinde birçok projede DEBUG ve DEBUGIN kullandım. Bence SERIN komutuna nazaran daha sağlıklı çalışıyor.

[Bahri Bilir]

İlyas bey yanıt için teşekkürler.Ama googlede debug kullanımıyla ilgili bilgiilere ulaşamıyorum.Önerebileceğiniz kullanımını basiteçe türkçe anlatan bir link var mı?


DEFINE DEBUG_REG PORTC
DEFINE DEBUG_BIT 6
DEFINE DEBUG_BAUD 19200
DEFINE DEBUG_MODE 1
DEFINE DEBUG_PACING 1000


Debugin [WAIT ("BLR"),dec5 A]

Bu şekilde denedim ama bunda da yine komut burada takılıyor ve resetlemeden bu komuttan ayrılmıyor.

DEFINE HSER_RCSTA 90h ' Enable serial port & continuous reve
DEFINE HSER_TXSTA 25h ' Enable transmit, BRGH = 1
DEFINE HSER_SPBRG 12  ' 9600 Baud @ 0,16%
DEFINE HSER_CLROERR 1 ' Clear overflow automatically

hserin 10,BASLA,[WAIT ("BLR"),dec5 A]

Bu şekilde yaptığımda tam istediğim gibi çalışıyor

[İlyas KAYA]

Hattı boşa mı çekiyorsunuz ? yoksa lojik sıfıra mı ?

[Bahri Bilir]

Hattı giriş olarak ayarlıyor 10k ile lojik 1 e çekiyorum

[İlyas KAYA]

Seri data RF de de çok sıkıntılı oluyor. Bu komutta çakılma sorunu beni de çok uğraştırıyor. Donanımsal olarak yaptığınızda bu sorunun üstesinden büyük oranda gelinebiliyor.

Ancak birbirine veri aktarmak yerine neden tek hattı kullanmıyorsunuz ? RS485 protokolü ile olabilir mesela.
Sistemi bilmediğim için çok fazla fikir yürütemiyorum.
Belki de yanlış bir yol izliyorsunuzdur.

[Bahri Bilir]

http://etepic.com/index.php/topic,2677.msg25524/topicseen.html#msg25524

Linkte elimden geldiğince sistemi biraz tanıtmaya çalıştım ama sizinde göreceğiniz üzere baya karışık.Kodları ve sistemi burada baylaşmaya kalksam konun 2 sayfasını bunlar doldurur. Ve pek uygun olmaz sanırım.

Ama sistem zaten tek taflı çalışma mantığına dayanıyor.Ama bu sürekli veri akımından bazı noktada verileri çekmem gerekiyor.

Örneğin 2 pic arasında tek taraflı sürekli bir veri akışı var.Ben bu verilerden birinde değişme olduğunda sadece değişen veriyi yine uart üzerinden başka bir pice almak istiyorum.Bunu aralarında sürekli trafik olan picleri meşgul etmeden başka bir picle yapmam gerekiyor..
Yani akan veriden bir kablo daha çekip 3. bir pice bu veriyi gireceğim.Bu pic sürekli verileri kontrol edecek ve eğer değişme varsa farklı bir usart üzerinden (yapmaya çalıştığımda kısmı bu,yani usartın biriyle sürekli akan trafiği alacak diğeriylede verilerde değişme olursa ana sisteme güncel veriyi gönderecek ) değişen veriyi ana sisteme gönderecek.Bu sayede o sürekli akan trafikten biz sadece bize lazım olanı seçip bir iki komutla ana sisteme gireceğiz.Ana sistem sürekli akan bu trafiği inceleyip duramayacağı için araya bu tarz bir işlem yapmam gerekiyor.


Bir diğer ve en güvenli,en sağlam çözüm olarakta ana sistemle 3. pic arası verileri parelel aktarmak geliyor aklıma ki bu picde çok fazla pine ihtiyaç olmasına sebeb olacak.Örneğin akan veriden 16 bit bir veriyi almak istediğimde ana sistemin 16 pinin sadece bu işe ayırmalıyım.Bunu hc595 ile yapsamda ortaya acayip saçma bir durum çıkıyor (akan trafikten veriyi usartla al,alıanan verilerde değişeni paralel olarak hc595 gir hc ilede ana sisteme ic2 ile aktar )

[İlyas KAYA]

Diğer konuda hayati önemden bahsetmişsiniz. İnsan hayatını konu alan kısımlarda seri haberleşme kullanılmaz. Kullanılsa dahi asenkron olmaz. Senkron bir yapı ile haberleşme yapılmalıdır.

Akış şemasında 18 adet ayrı cihaz görünüyor. Haberleşmeyi alan ana PIC 18 ayrı PIC'i 5 bit hat ile sadece uyarsa daha sağlıklı olacaktır.
Hayati önemi olan bir alanda PIC kullanmak ne kadar mantıklı tabi ki buda tartışılır.
illa PIC kullanılacak ise ;

PIC ler arasında yine SPI veri aktarmak için daha makuldur.

http://ondergormez.com/2015/02/05/spi-ile-picler-arasi-haberlesme/

[Bahri Bilir]

İlyas bey ilginiz ve yönlendirmeleriniz için çok teşekkür ediyorum.Seri iletişimdeki veriler evet %80 hayati önem taşıyor.Yani veriler hatalı ulaştığında kullanan kişinin sağlığını riske sokabilecek nitelikte.Ama veri aktarımını sağladıktan sonra da veri hataları için güvenlik şalteri çalışmaları düşünüyorum.Yani eğer verilerde en ufak bir sıkıntı yaşanırsa (örn gelen 3 veri tam anlaşılmadı ise gibi...) makina gücü kesilecek tarzda güvenlik çalışmaları yapmayı planlıyorum.

Önerilerinizi de dikkate alarak çalışmalarımı gözden geçireceğim.

İyi çalışmalar dilerim.

[F®T]

Şahsen düşüncem bu  tip otomasyon uygulamalarının plc ile yapılmasını tercih ederim.Ama veri toplama olsun gösterge gibi işlerde işlemci olabilir.Çünkü  herşey yazılımda bitmiyor.

[Bahri Bilir]

Şahsen düşüncem bu  tip otomasyon uygulamalarının plc ile yapılmasını tercih ederim.Ama veri toplama olsun gösterge gibi işlerde işlemci olabilir.Çünkü  herşey yazılımda bitmiyor.

F.T önerin için teşekkürler.Son zamanlarda bu PLC yi daha fazla duymaya başladım.Açıkcası sadece hakkında genel bilgiler biliyorum.Ne herhangi bir modelinin ayrıntısına girdim nede daha önce bir uygulamada kullandım.
PLC bana pek mantıklı gelmiyor.Yanlış anlmayın bir iş yapıyorsan hazıra kaçmayıp en derinine kadar ineceksin demiyorum.Sadece orta seviyede de olsa pic programlama bilipte plc kullanmak saçma geliyor.Sebebi bu plc lerin, piclerin (microişlemcilerin) belli kalıplara sokulup bu kalıplar çerçevesinde işlem yürütmesinden ibaret olduğu konusunda hem fikirsek senden bir başkasının tasarladığı kalıpları kendi tasarlayabileceğiniz kalıplardan üstün görelim ki?

Yani belki bu gün plc tasarlayanlar kadar olaya ve kodlara hakim değiliz.Ama bu bizim hobimizse (işimizse) yarın onlardan iyi tasarlayabilmek adına çözümü daima sınırları zorlayarak aramayı uygun buluyorum. Ve bu ETE hocam ve diğer forum üyeleri gibi paylaşımcı kişilerle olduğumuz sürece inanın çok yakın.

İyi çalışmalar.

(Yukarıdaki iletimin tek sebebi düşündüklerimi sizinle paylaşıp sohbet ortamında fikirlerinizi duymak istememdir.)

[Bahri Bilir]

Ama aşağıdaki kodu kullandığımda döngü koda gelip donuyor."gir" değişkenine tanımlı pine sürekli olarak veri akıyor.Eğer gir değişkeninin tanımlı olduğu pinin veri akışını keser tekrar verirsem döngü 1 tur atıyor ve tekrar komuta gelip kalıyor.

SERIN2 gir,12,10,BASLA,[WAIT ("BLR"),dec5 A]

Aşağıdaki şekilde de denedim sonuç aynı.Tek fark bu sefer gir pininin akışını kessemde döngü komuttan ayrılmıyor.

SERIN2 gir,12[WAIT ("BLR"),dec5 A]

Arkadaşalar henüz problemi çözemedim.Yardımlarınızı bekliyorum.

Bu arada 1. Kodda (SERIN2 gir,12,10,BASLA,[WAIT ("BLR"),dec5 A]) veri alınamadığında BASLA etiketine gitmesini söylüyorum.Ve "SERIN2 gir,12,10,BASLA,[WAIT ("BLR"),dec5 A]" kodunu diğerkodlardan sonra döngünün en sonuna koyuyorum.Yani eğer10 ms içinde veri gelmediğinde BASLA komutuna gitseydi döngü sıkıntısız çalışacaktı.Ama sıkıntı göngü bu satırda donuyor.

Örneğin:

BASLA:

if LED2=1 then
LED3=1
endif

if LED1=1 then
LED2=1
endif

LED1 =1

SERIN2 gir,12,10,BASLA,[WAIT ("BLR"),dec5 A]

goto BASLA

Şeklinde yazdığımda ilk enerji verildiğinde sadece led1 yanıyor.Veri hattını kesersem led2 de yanıyor.Ve eğer tekrar veri hattını verip kessersem led3 yanıyor.

Sorunu sonunda baya net anlatabildim sanırım..

[İlyas KAYA]

Veri hattı zaten bağlı değil mi neden boşa çıkartıyorsunuz ? Boşta kalmaz ise hiçbir sorun olmayacak. Şöyle ki normalde 1 verisi sürekli alıcılara gider siz 1 verisini değerlendirme dışı olarak işleme tabi tutarsınız.

Veri sürekli geldiği için komutta çakılma da olmayacaktır. Aksi halde donanımsal "hserin" ile çalışmanız gerekecek. Kaldı ki hserin de bile ara ara süre verdiğimiz 10 ms den fazla olabiliyor.

[Bahri Bilir]

İlyas bey benimde anlamadığım nokta orası.Sizin dediğiniz gibi veri hattından sürekli veri geldiğinde donma olmaması gerekiyor.Ama veri hattından sürekli veri gelmesine rağmen döngü bu koda gelip donuyor

Belki veri alış parametrelerinde  bir hata yapmışımdır deyip hserinle deniyorum sıkıntı yok veri güzel alınıyor.Ama serin2 de veri hattını kesmezsem döngü serin2de donup kalıyor.Eğer hattı kesip tekrar bağlarsam 1 tur daha atıyor.