Usartsız haberleşmede shift in sorunu

[m_aktaran]

Merhabalar,

Usartsız haberleşmede proton basic ile proteus simülasyonunda shin ve shout komutları ile yaptığım denemelerde şu sorunla karşılaştım.

Devreyi kurarken, benzer konularda anlatıldığı gibi davrandığımı düşünüyordum. Önce verici kartta i2cout ile veri gönderirim, alıcı kartta da i2cin ile okurum diye düşünmüştüm.

Donanımsal i2c kullanmadığım için (ki zaten mcu'da böyle bir modül yok) yazılımsal i2c haberleşmesinde i2cin komutu master olarak slave cihazdan veri okuduğunu düşündüğü sonucuna vardım. Proton basic dokümanlarında i2c slave modu diye bir şey yoktu.

Benzer konularda tarif ettiğiniz gibi usartsız spi ile yani shout ve shin komutları ile sorunu çözeceğimi beklerken, alıcı taraf mcu'da (16f628a) clock pini vericiden gelen sinyali okumak yerine, clock sinyali üretiyor. Sanırım slave olarak tanımlanmadığı için sanki eeprom okur gibi clock üretiyor.

Bu konuda ya benim konuya bakış açımda bir noksanlık var, ya da ısrarla bir şeyleri hatalı yapıyorum.

Son olarak şu düşüncedeyim, shin komutu da i2cin gibi master modda okuma yapıyor. Bu şekilde haberleşme yapmam zaten mümkün değil. Ama bunu slave moda nasıl getirmem gerektiğini bulamadım.

Spi ile iki mcu arasında haberleşme yapmak için donanım (usart) ayarlarını düzenleyip çalıştırmak şart mı?

Değilse bunun yolu nedir? Değerli cevaplarınızı bekliyorum. Şimdiden teşekkürler.

Verici tarafı:

    High spi_cs
    DelayMS 10
    SHOut  spi_copi, spi_sck, 1, [ongassure]
    DelayMS 1000
    Low spi_cs
    DelayMS 1000

Alıcı tarafı:

    While spi_cs = 0
    Wend

    ongassure = SHIn spi_copi, spi_sck, 1, 8
    EWrite 0, [ongassure, 0]
    DelayMS 10

[ete]

Haberleşmenin temeli  iki ünite arasındaki senkron tutturmaya dayanır.
Taraflardan birisi diğer taraf ile haberleşmek istediğinde karşıdakide haberleşmeye hazır olmalıdır. Sonuçta bu iş bir clk palsi ile yapılıyor ve aynı anda bu palslerin iki taraf için çalışması esastır. Haberleşmeyi daima master yönetir. CLK palsini o üretir ve Slave de aldığı bu clk palsi ile işlem yapar.

Bu iş öyle sanıldığı kadar kolay bir iş değildir. Ben bilgiyi yolladım (yada istedim) karşıdaki de verir diye düşünmemek gerekir. Arada bir tampon olursa (donanımsal modül) işiniz elbette kolaylaşır. Ama buda her zaman mümkün olamıyor maalesef.
Kısaca sizin sorununuz büyük olasılıkla senkron sorunu.
SPI_CS diye bir pini senkronizasyon için kullanmışsınız bu doğru bir hareket ama verici tarafında SPI_CS pinini set ettikten sonra koyduğunuz o 10ms lik gecikme bile senkronu bozabilir. Kaldırıp deneyin. Gecikme komutları senkronizasyonun baş düşmanıdır.
Proton ile çalışmadığım için genel konuşmaya çalışıyorum. Komut kullanımınız da yanlış olabilir. Bunuda araştırmanızı öneririm.
Bu konularda epeyce uğraşmış bir kişi olarak naçizane tavsiyem verici tarafında standart bir serial komut ile bilgi yollayın ama alıcı tarafında daima kesmeye dayalı bir USART komutu kullanmaya çalışın İşin emniyeti açısından bu neredeyse mutlak gereklilik. Aksi halde sürekli senkron sorunu yaşarsınız. Bu sistem size rahatlık sağlar. Sürekli bilgi geliyormu diye bakmanız gerekmez işinize bakarsınız sistem bilgi geldiğinde kesme yaratır sizde gider alırsınız o bilgiyi.

Ete

[alisumer]

donanımı kullanılmayacaksa en yakın verimi CS ve CLK sinyalleri için iki değişiklik kesmesi bacağı kullanarak yakalarsınız.(tek alıcı kullanacaksanız CS pinine ihtiyacınız olmaz )cs sinyali geldiğinde kesime gider bacağı kontrol eder ve alıcıyı hazırlamak için Örneğin CS adlı bir değişkene 8 verisini yazarsın ve kesmeden çıkarsın. ilk saat darbesi geldiğinde tekrar kesmeye girer kesme alt programında hangi bacağın kesmeye neden olduğunu kontrol edebilirsin eğer CLK sinyali ise ve CS bacağı da 0 ise  Data bacağından gelen veriyi başka bir değişkenin içerisine kaydırırsın kesmeden çıkarken de gelen datanın uzunluğunu belirttiğin değişkeni bir azaltır bayrakları indirir çıkarsın.böylece önemli bir kayma yaşamadan verileri alabilirsin.ASM için gözümde canlanıyor sıkıntı olmazda diğer diller ana programda paus tarzı gecikmeler kesime girmeyi geciktirebildiği için sıkıntı çıkarabilir belki kesmeden çıkınca iletişim bitene kadar meşkul olmayacağı bir alt programda bekletmeniz daha iyi olur.