sn75176 RS485 Haberleşme mesafe sorunu

[OG]

Bu ters polarmanın Pin1' i low'a çekmesi demek Pic için start demektir..Yani data alınmaya başladığı zaman Pin1 low olur ve sonunda yine high olur..

Doğru. Ama ben farklı bir mantıkla kullanıyorum. İletişimde tıkanmaları bu şekilde aştım.

Hat boş zamanlar için hep low da bekliyor.
Alıcı pic'ler asıl işi arasında belli aralıklarla hatta bakıyor, low ise işine geri dönüyor, bir iki saykıllık kayıp süre.
H ise datayı bekliyor. Zaten datanın alınabilmesi için başlangıçta H olmalı ki (true iletişim için) start bite inişi görülsün ve time değerleri doğrulansın. Bekleme süresi de veriyorum, o sürede gelmezse tekrar işine dönüyor.
Datayı gönderen üniteler de zaten başına bir header tanımlama bilgisi eklediğinden (  https://www.picproje.org/index.php/topic,16623.msg109571.html#msg109571 ), alıcı konumundaki öncelikle o bilgiyi bekliyor.

[My75]

Değişik bir mantık,bu durumda uart donanım nasıl kullanıyorsunuz? Çünkü donanım low'u görür görmez start diyecek 8 bit işleyecek ve stop bekleyecek yani takılacak....Kafam karıştı

Sanırım anladım,

Ters polarmadan dolayı tüm alıcıların Ro çıkışları low,herhangi bir ünitenin txen pinleri high olunca polarma değişiyor ve Ro çıkışları high oluyor..Bu durumda siz askerleri bekletiyorsunuz..Doğru anlamışmıyım??  Uart'da sorun olmuyormu?*

[OG]

UART ile veya yazılımsal farketmez, hat low ise data alışa geçmez geri döner,

high ise

SERIN ..
veya
HSERIN ..

der data bekler.

UART da sürekli alış biti kapalı durur, H görünce açarsınız.

[My75]

Anladım zaten yukarıda editledim..Peki aykırı bir durum değilmi? Sanırım sadece kendi ürünlerinizde kullanıyorsunuz bu yöntemi? Dmx modüller yapıyordunuz sanırım sorun olmuyormu?

[OG]

Valla buna kişisel tercih deyin. Belki kulağı tersten tutmak ama, aynı hatta çok ünitenin çift yönlü haberleşmesinde tıkanıklığı ancak bu şekilde çözdüm. Tek yönlü DMX için buna gerek yok ama bende alışkanlık oldu, her iş için hattı ters polarmalandırıyorum. Aynı mantıkla data takip ediyorum.

[Pyrodigy]

Valla buna kişisel tercih deyin. Belki kulağı tersten tutmak ama, aynı hatta çok ünitenin çift yönlü haberleşmesinde tıkanıklığı ancak bu şekilde çözdüm. Tek yönlü DMX için buna gerek yok ama bende alışkanlık oldu, her iş için hattı ters polarmalandırıyorum. Aynı mantıkla data takip ediyorum.

Usart data alımlarınızda (bit banged değil) Kesme kullanıyormusunuz?

[OG]

Genelde kesme kullanmam, kolay olanı tercih etttiğimden sanıyorum. Kesmede "nerede kalmıştım" meselesini fazla düşünmemek için, yani tenbellikten.

[Pyrodigy]

Genelde kesme kullanmam, kolay olanı tercih etttiğimden sanıyorum. Kesmede "nerede kalmıştım" meselesini fazla düşünmemek için, yani tenbellikten.

Hocam sizin ters polarlama methodu sadece bitbanged alım gönderimlerde çalışır. Gömülü USART modüllü çiplerde data alım - gönderim çalışmaz. Çünkü başlangıç biti yok yani hep sıfıra çekili zaten..

[OG]

Ama bakın hat LOW ise data alımı ile uğraşmıyorum zaten. High ise Hserin diyorum. USART da sürekli alışta (RCSTA.4 =1) olmak zorunda kalmıyor.

[Pyrodigy]

Ama bakın hat LOW ise data alımı ile uğraşmıyorum zaten. High ise Hserin diyorum. USART da sürekli alışta (RCSTA.4 =1) olmak zorunda kalmıyor.

Hocam siz USART Senkron iletişimmi kuruyorsunuz? Çünkü Senkron iletişimde Start ve Stop bitlerine gerek yok.

[OG]

Hayır asenkron 8N1, 8N2,
250.000'e kadar çok değişik değerlerde.

RCSTA.4 =1 demekle kastettiğim bunu 0 yaparsanız zaten USART oto alış yapmaz.
Hattı HIGH görünce RCSTA.4 =1 yaparsınız start bitini bekler (RCSTA.4 =0 ve sonra RCSTA.4 =1 yapmak usartı da temizler). Bu bekleyişe de bir miktar süre koyarsanız,

alinmadi = 0
HSerIn 5, bekleme, [x]   ' 5ms data bekler
return

gibi

bekleme:
alinmadi = 1
return

etiketindede alınmadığını gösterirseniz bir çok işde kesmeye gerek kalmaz

[jackal183]

CCS C kullanıyorum, pc'den veriler şu şekilde geliyor:
'A'
delay_ms(1);
'B'
delay_ms(1);
'C'
delay_ms(1);
'D'
delay_ms(1);
'cihazadresi'

ve rx interruptım şu şekilde

#int_RDA
void seri_kesme(void)
{
   int data;
   
   data=getch();
   if((data==adres) & (gelensayisi==0))
   {
      gelenveri[gelensayisi++]=data;
     // cevapgonder();
   }
   else if ((gelensayisi==1))
   {
      gelenveri[gelensayisi++]=data;
   }
   else if ((gelensayisi==2))
   {
      gelenveri[gelensayisi++]=data;
   }
   else if ((gelensayisi==3))
   {
      gelenveri[gelensayisi++]=data;      
   }
   else if ((gelensayisi==4))
   {
      gelenveri[gelensayisi++]=data;
      datageldi=1;
      
   }

}

interruptan sonra main code şu :

while(1)
   {
      if(datageldi)
      {
         datageldi=0;
    
            cevapgonder();
         
         gelensayisi=0;
      }
 
   }

cevapgonder fonksiyonum ise şu şekilde;

   output_high(txen);
   delay_ms(20);
   printf("FG%c%c%c", buton1, buton, adres);
   delay_ms(20);
   output_low(txen);

iletişim için yazılan başka kodları incelediğimde bu çok sağlıklı bir yöntem gibi görünmüyor çünkü checksum yok, ancak benim cihazlarıma veriler sürekli geliyor gidiyor, sistem 16 adet cihazı sırayla soruyor ve 16 dan sonra tekrar başa dönüp yine sormaya devam ediyor.

yazılımda bu kısmı nasıl daha sağlıklı hale getirebilirim?

Bugün hattın en sonuna bir pc daha koydum ve bu pcde sadce com porttan gelen giden dataları inceledim. Hattın başında PC(master)den veriler sürekli ve sağlıklı şekilde geliyor. hattaki cihazlar da yine başlangıçta sağlıklı bir cevap veriyor, ancak kısa zaman sonra bazı cihazlar artık hiç cevap vermemeye başlıyor. Bazen de cevap veriyor ancak bozuk datalar, yani gelmemesi gereken cevaplar geliyor. Ben de bu yüzden sorunun yazılımsal olduğuna kanaat getirdim. Ancak nasıl bir sorun olduğunu çözebilmiş değilim.

pc programı tarafında kodu ilk yazdığımda datalar arasında delay_ms(1); beklemesi yapmamıştım, sistem yine aynı şekilde çalışıyordu. daha sonra acaba dedim cihazlarda rx interruptının içindeyken o anda başka bir veri daha geliyor ve çakışma yaşanıyor olabilir mi? bu yüzden de böyle bir bekleme koydum.

[OG]

jackal183, kullandığın dili bilmediğimden yardımcı olamıyorum, yanlızca iş üzere kendi kullandığım dilden mantık yürütüyorum.

[jackal183]

hocam pc programı tarafında delphi ve gömülü yazılımda CCS C kullanıyorum

[ferdem]

Bu tarz sorunları yakından çözmek bile zor olabiliyor, uzaktan daha da zor. En baştan söyleyeyim en kalabalık(!) 485 network üm 4 elemanlıydı ve max kablo uzunluğu 30-40 m idi. Hocam kablo uzadıkça ve hız arttıkça hatta yansımalar görülür, hattın uzunluğu ve elemanların yerleşimine göre yansıyan voltaj dalgaları serseri kurşun gibi nerede nasıl bir bit hatasına yol açar bilinmez. Uzun hatlarda hattın sonuna 120ohm şart, 2K2 ler bana az geldi çünkü 10 ünitede 220 ohma düştü zaten... 220 de aşağıda AC de 110 ohm görünecek. Ben pull up ve down yapmamıştım ama en azından arkadaşların tavsiye ettiği gibi 22K gibi daha yüksek bir değer kullanın.
Sistemde bir süre sonra çalışmayan elemanları fark ediyorsunuz, bu elemanları resetlediğinizde de hâlâ cevap vermiyorlar mı?
Çalışanla çalışmayanın yerini değiştirip tüm sisteme reset ten sonra tekrar gözlediğinizde sabıkalı eleman düzeliyor mu? Sorun yerleşimden mi elemandan mı bakılabilir.
Yazılımı da çok sade yapmışsınız... adresler hatta ünik tek mi? Hatta bir byte adresini gören dizginleri ele alıyor, sonrasında söyledikleri arasında başkasının adresinin olması kazara da olsa ihtimali nedir? Çakışma riski yüksek durumlar bunlar... Standart bir protokolü sisteminize yerleştirin veya kendiniz basitçe bir protokol belirleyin. Bir paket formatı belirleyin, her pakette muhakkak preamble olsun... Benim kullandığım paket formatı ve örnek kodu aşağıya koyuyorum:

#define frame_size 5

// PACKET FORMAT: PREAMLBES(2BYTES):36,36 - DEST(1BYTE) - SOURCE(1BYTE) - PAYLOAD(2BYTES)- CHCK BYTE
// LATCHED FRAME: DEST(1BYTE) - SOURCE(1BYTE) - PAYLOAD(2BYTES)- CHCK BYTE

// COMMAND LIST: PAYLOAD(2 BYTES)
//...

Kesme içeriği:

prev_data=data;
data=getc();
if(data==prev_data && prev_data==36){ //preamble is received, make subsequent bytes be latched
   en_latch=1;
   return;
}
if(en_latch==1){
   frame[frame_index]=data;
   frame_index++;
   if(frame_index==frame_size){//frame is latched, disable latch and clear index
      en_latch=0;
      frame_index=0;
      
      if(frame[0]==adres){//the new frame is for me
         new_frame=1; 
         output_toggle(led); 
      }
   }
}

Ana döngüde new_frame i kontrol ediyorum, 1 ise "process_frame" çalışıyor.
PIC UART hardware de adres byte/data byte tanıma gibi bir özellik var ama ben kullanmadım, bakılabilir. İyi çalışmalar, kolay gelsin.

Düzenleme: Kelime hatası düzeltildi. "ünik" ne demek!