Seri İletişim ve TMR0 Kesmesi Sorunu

[erdemefe]

Hocam ben sorunu anladım galiba her kesme oluştuğunda INCON.7=0 olarak kesmeler iptal edildiği için USARTdan dolayı kesme oluştuğunda bilgi alınırken geçen sürede TMR0 kesmesi gelse bile işleme alınmıyor bu da zamanın uzamasına neden oluyor.

Eğer sorun bu ise nasıl aşılabilir?

[ete]

Aşılması mümkün değil. Ancak etkisi azaltılabilir.
USART kesmesinde Timeout değeri girebilir ve USART da programın fazla beklememesini sağlayabilirsin. Mesela
HSERIN 5,ATLA, [WAIT ("EFE"),ISIB.LOWBYTE,ISIB.HIGHBYTE,ISARETB] şeklinde bir komut satırı enfazla 5 ms bekler.
Rakamı kurtardığı oranda azaltabilirsin.

Programındaki yeni kesme kısmıda sorunlu gibi gözüküyor. Yada lüzumsuz satırlar var.
KESME:

IF RCIF=1 THEN RCI

    SAYAC=SAYAC+1
        IF SAYAC=61 THEN
        SAYAC=0
        SN=SN+1
        toggle PORTB.5
        ENDIF
T0IF=0
GOTO KESME_CIK

RCI:
HSERIN 3,atla,[WAIT ("EFE"),ISIB.LOWBYTE,ISIB.HIGHBYTE,ISARETB]   'SICAKLIĞI VE İŞARET BİTİNİ AL
ATLA:
TEMP=RCREG
KESME_CIK:
RESUME
ENABLE

şeklinde kullan.

Ete

[erdemefe]

denedim hocam 3-4 ms kurtarmıyor 0 yazıyor, 5 olunca kurtarıyor ama yine bir orantısızlık sözkonusu iletişim varken 1.35 sn yokken 1 sn olarak görünüyor.
baud rate'i 9600e çıkartığımda bayağı azaldı fark 1ile 1.1 sn arasında falan oldu fakat bu seferde program anlamsız yere hot ve cold etiketlerine kaçmaya başladı. hem de alıcıdaki sensörden gelen bilgi yüzüneden (kablolu sensör) gerçekde denediğimde ise hot etiketinden çıkmadı bile hep orada kaldı

[ete]

O zaman taktik değiştirmen gerekecek. Madem 5 ms kurtarıyor. Demekki seninde en azından 10 yada 50 ms lik saat pıulsları kullanarak 1000 ms yi tamamlaman daha doğru olur. Böylece usun zamanlı kesme USART kesmesinden etkilenmez.
Gerekirse TMR0 değilde TMR1 kesmesi kullanarak bu işi yapman lazım.

Ete

[erdemefe]

denedim hocam 256 bölme oranında 15 kesmede 1 artırdım. Fark bayağa azaldı 8 saniye üzerinden ölçtüm isisin skobunda, verici bağlı değilken iken 7.88sn bağlı iken 8.35 sn ölçtüm TMR1 kesmesi nasıl kullanılıyor avantajı ne olacak onu kullanayım eğer daha da azalacaksa

Birde aklıma geldi harici bir kristali saydırarak palsleri yakalamamız mümkün değil mi?

okulda gördüğümüz 8051de kesme önceliği diye bir özellik vardı kesme kaynağına öncelik verirsek program başka kesmede bile olsa önce öncelikli kesmeye atlıyordu picde bu mümkün değil mi?

[ete]

Sonuç fazla değişmeyecek demektir o zaman. Yapacak bir şey yok gözüküyor.
Ete

[erdemefe]

harici kristal ve kesme önceliği konusu sorunu çözmez mi hocam ?

[ete]

Aynı anda kesme oluşması sorununa çözüm bulmadıktan sonra ( bir çözüm varsa elbet) bu sorun giderilemez gözüküyor. Olaya da tam vakıf değilim. Bu kesme de yalnızca sn pulslerini elde ediyorsun . Saat için ayrıca dakika ve saat değerlerinide elde etmen gerekmiyormu?
İşin çözümü bir tane rtc kullanmaktan geçiyor bence.
Ete

[Mucit23]

Pic Mikrodenetleyicilerinde Usart için Dahili Buffer yokmu? Neden veri geldiği zaman kesme başında veri gelmesini bekleyelimki, Veri geldiği zaman kendisi buffere doldursun. Sonra kendisi isterse kesme flagını set etsin bizde gidip hiç beklemeden gedip Rx bufferini okuyalım. Hatta 18F de kesmelerde öncelik meselesi var. Çözülebilecek bir problem gibi görünüyor.

[ete]

Usart buffer'ı var elbette. Standart veri yollarsan ve yolladığın verı 1 byte ise kesme oluştuğu zaman gelen bu 1 byte veriyi rcreg registerinden alırsın. Ancak parazit de gelse alırsın sana ait olmayan veride gelse onu alırsın. Bu yüzden wait komutunu kullanıyoruz. Yalnızca bize ait olan veriyi alabilmek için. Yinede  port başında beklemiyoruz değilmi. Kesme oluşunca port başına gidip gelenleri almaya çalışıyoruz.

Kesme önceliğine gelince işin içinde saniye verisini oluşturacak ve her 16 ms de bir oluşması gereken bir kesme olunca hem usart dan geleni kaçırmayayım hem sn kesmesini kaçırmayayım diyorsan ne yapsan nafile. Sn kesmelerine öncelik verdin diyelim ne anlama geliyor bu? Aynı anda kesme oluşmuş ise sn kesmesi dikkate alınarak kesme etiketine git anlamına geliyor. İşlemci zaten oluşan her kesme cinsi için bayrağını set ediyor. Sana düşen bir kesmeyi işlerken çıkmadan önce diğer kesmede oluşmuşmu bakmak oluyor. Sn kesmesi gecikmeye uğrayabilir. Bunu usart kesmesi geciktirebilir ancak. Ama usart kesmesi gecikmeye tahammülü yoktur. Veri ye sen birazmdur ben şu sn işini halledeyim sonra seni alırım diyemezsin. Ortak bir çıkar yol bulmak lazım. Aklıma gelenleri uyguladık. Bundan ötesini ben bilmiyorum. Senin başka fikirlerin var ise genel anlamda olabilir diye konuşmayıp direk çözüm önerisinde bulunmanı bekliyorum.
Ete

[Mucit23]

Hocam şuanda konuya tam yoğunlaşamıyorum. Ama kesme başında beklemek bence düzeni bozuyor. Piyasada satılan Normal ARX, ATX modüller çok kalitesizler, normal çalışmada data yokken alıcının TX pininden aklınıza gelecek her türlü data çıkıyor. Verici data gönderdiği zaman ise bu dataların hepsi bir anda kaybolup gelmesi gereken datalar geliyor. Buda gereksiz yere bufferi dolduruyor.
Bu konuda problemi olmayan modüller var. Onlardan kullanılarak Parazit sorunun aşılabileceğini düşünüyorum. Fakat bu işde maliyeti arttıracaktır. Bu modüller çok pahalılar. Dediğiniz gibi bir RTC ile ve işlemcinin RTC için ayıracağı en az iki pin ile sorun kökten çözülür.

Şimdilik Aklıma Başka yöntem gelmiyor. Ama bu konu üzerine kafa yoracağım.

[erdemefe]

Erol hocam Ferhat kardeş cevaplarınız için sağolun

RTCden bahsetmişiniz ama burada benim saniye palslerini yakalamak istememin tek nedeni hangi sensöreden gelen bilginin ekranda kaç sn kalacağını ayarlamak 1sn 1.2 sn çok fark etmiyor aslında ama çözüm varsa tabiki uygulamak istedim. şu anda farkı daha büyük bölme oranı ile minimuma indirdim galiba işimi görür artık.

[Mucit23]

RTC kullan dememizin sebebi zamanın hassas olmasını sağlmak değil. RTC nin amacı senin timerlerle zaman işleriyle uğraşman yerine RTC nin bu işi yapması. Ama problemi büyük ölçüde çözmüşsün sanırım.

[erdemefe]

hocam devreyi hala devam ettiriyorum şimdi sıra termostat kısmına geldi termostat kısmında ayarlanabilen değer -50 ile + 99.9 derece olması gerekiyor yani program içinde -500'den +999a kadar sayan bir sayıcı yapıp bunu eeproma yazmam gerekiyor ama biraz sorun yaşadım hemen kodu ekleyeyip sorumu sorayım.

TERMO_AYAR:
WHILE MODE=0 : WEND


IF ARTIR=0 THEN
HAM2=HAM2+1
    IF HAM2>999 THEN 
    HAM2=999
    ENDIF
'WHILE ARTIR=0 : WEND
ENDIF

IF EKSIL=0 THEN
HAM2=HAM2-1
'    IF HAM2<65485 THEN
 '   HAM2=65485
  '  ENDIF
'WHILE EKSIL=0 : wEND
ENDIF

IF HAM2<65035 THEN
AYAR_ISR=0
AYAR=HAM2
ENDIF


IF HAM2>=65035 THEN
AYAR=$FFFF-HAM2+1
AYAR_ISR=1
ENDIF]

FOR I=0 TO 1000
PAUSEUS 5
NEXT I

WRITE 2,HAM2.LOWBYTE
WRITE 3,HAM2.HIGHBYTE

SN=0
SAYAC=0
TMR0=0
IF MODE=0 THEN BASLA
GOTO TERMO_AYAR

burada ham2 değişkenini içeriğini saydırarak pozitif değerlerde direk ayar değişkenine eşitleyip AYAR_ISR bitini 0 yapmaya negatif değerlerde de 65535den HAM2'yi çıkarıp 1 ekleyerek AYAR_ISR bitini 1 yapmaya çalıştım

sayarken 0ın alltına düştüğünde tekrar yükseltmek istedğimde 65035 den büyük ya da küçük olma şartında sıkıntı yaşıyorum ayar değişkeni direk 999 oluyor 0ın altına düşüp düşmediğimi nasıl kontrol edebilirim mesela assembler dilinde küçük sayıdan büyük sayıyı çıkardığımızda carryflag 1 oluyordu pic basic proda öyle bir durum yok mu? bu sorunu nasıl aşabilirim?

[ete]

Çalıştığın sayılar 0-1000 arasında ise sayı negatif olduğu zaman Bit15=1 olur mutlaka.
Bu nedenle ;
IF SAYI.bit15=1 then sayı=~SAYI  demen yeterli olur.

Ete