rc kontrollü devrede enerji tasarufu sleep, @sleep ve nap komutlarının kullanımı

[greatgonzo]

  Arkadaşlar şu sıralar uğraşmakta olduğum rc kontrollü devrede biraz sıkıştım. Şöyleki devremi pille çalıştırmak istiyorum ve sürekli olarak dinleme konumunda olacak. Dolayısıyla enerji tüketimi ön plana çıkıyor. Bu bağlamda ilk planım usart kullanarak iletişim sağlamak idi. Bu noktada birşeyi fark ettiim (yanlışım varsa lütfen düzeltin) sleep ve @sleep komutları ile işlemciyi uyuttuğumuzda kesme gerçekleşmiyor. İnternette pek çok bölük pörçük kaynakta bu böyle görünüyor. Sleep ve @sleep komutları rb0 rb4-7 kesmelerinde işlemciyi uyandırıyor. Yani fiziksel kesmelerde.
  İlk aklıma gelen TX bacağı ile Rb0 bacağını köprülemek ve gelen veri ile eş zamanlı rb0 kesmesi oluşturmaktı. Ama alıcı modüldeki parazitler işlemciyi uyuması için ne kadar rahat bırakacak yada iki bacağı köprülemek ne kadar sağlıklı olur.
  Bana göre bir diğer çözümde kısa süreli uyutmak. Nap yada sleep komutlarıyla 0.25 saniye yada 0.50 saniye gibi sürelerde aynı
pause 200 komutu yerine 200 tane  1ms döngü oluşturmak gibi. Acaba bunun faydası olurmu. Yani yazılımın çalışmasında yada donanımsal olarak karasızlığa sebep olurmu. Ayrıca sleep ve nap komutu için tımer gibi ek donanımların çalışması ile tüketilen enerji miktarını ne kadar arttırır.
  Bir diğer soru işaretide bu süre içinde gelen veride kayıp olusurmu. Yani usart gelen veriyi tamponlayıp kesme bayrağını 1 yapıp uyanmayımı bekler ? Ayrıca bu sürede veri kayıpları olasımıdır.
  Yukarıda yazdıklarımdan farklı olarak başka birşey daha paylaşmak isterim. serout2 komutuyla gönderilen veriyi hserin komutunun problemsiz aldığını gördum. En azından isis simülasyonu böyle. Bunu gönderilen veriyi 4-5 defa tekrar etmenin faydalı olmasından dolayı denedim.  Seri çıkış olarak ayarladığım pinle alıcı pic in tx bacaklarını bağladım. Simülasyon gayet problemsiz çalıştı.
  Son olarakta sormak istediğim pic in enerji tükerimindeki diğer etkenler. Bazı forumlarda bunlar tartısılmıs fakat emin olamadım. Kimi boşta kalan bacakların çıkış olarak ayarlanıp ground a çekilmesini söylüyor kimisi direnç kullanarak bu işlemin yapılmasını tavsiye ediyor. Rivayetlere göre  hem daha az enerji tükerip hemde devredeki diğer elemanların oluşturduğu dalgalanmalara karşı pic in daha duyarsız davranacağını söylüyor. Bir diğer görüşte boşta kalan tüm bacakların +5v a bağlanması yönündeydi. Acaba bunların hangisi doğrudur teknik olarak.

[greatgonzo]

    Arkadaşlar @sleep komutuyla ilgili ilerleme kaydettim. Yabancı sitelerdede tartışılan bir konu. Benzer sivri çözümleri tartısıyorlar.Ama 16f877 16f628 lerdede olan bir özellik. Beni yanıltan nokta ise 628a ile yaptığım denemede 1 byte veri ile denemiştim. Oysaki 628a ların kesme oluşturup uyanmak için ihtiyacı olan en az 2 byte veriymiş. Gerçektende isis simülasyonundada bu şekilde oldu. 2 Byte veri ile gerekli kesmeyi üretiyor. Ayrıca bana göre dikkat edilcek diğer husus preamble uyanmayı sağlamıyor. Dolu dolu 2 byte veri aldıktan sonra kesme oluşturuyor. Eğer 1 byte yollarsanız onuda ilgili yazmaçta muhafaza ediyor. 2. byte gelmesiyle beraber uyanıyor.
   

pic16f628 datasheette böyle bahsetmişler.

12.5.1 USART SYNCHRONOUS SLAVE
TRANSMIT
The operation of the Synchronous Master and Slave modes are identical except in the case of the SLEEP mode. If two words are written to the TXREG and then the SLEEP instruction is executed, the following will occur:
a) The first word will immediately transfer to the TSR register and transmit.
b) The second word will remain in TXREG register.
c) Flag bit TXIF will not be set.
d) When the first word has been shifted out of TSR, the TXREG register will transfer the second word to the TSR and flag bit TXIF will now be set.
e) If enable bit TXIE is set, the interrupt will wake the chip from SLEEP and if the global interrupt is enabled, the program will branch to the interrupt vector (0004h).

[BAHAR]

Uyku modundan çıkma sebeplerinin en başta gelenleri;

* Watchdog timer
* Pinlerden birinin değerinde ki değişme
* Portb'nin 0 biti

Portb'nin 4 ila 7 pinleri üzerinde meydana gelecek bir değişme ise pic'i uyandırmaya yetebilir ki bunun için intcon ve option_reg yazmaçlarının ayarlanması gerekir. İlk olarak portb'nin zayıf pull-up'larını açmak gerek bu da option_reg.7'nin yani rbpu'nun temizlenmesi ile mümkün olur. bu işlem yapılmaz ise pin başı boş durumda olacağından pic herhangi bir durumda uyanabilir. yani bir kesmenin devreye alınmış olması gibi bir etkisi vardır. Bu durumda portb'de ki her olay pic'in kesme kontrolüne zıplamasına yol açar bunun için ise de gie'nin, yani intcon.7'nin temizlenmesi gerekir.

[greatgonzo]

Bahar arkadasım haklısın ama karşılastığım problem maddi değilde manevi kesmeler idi Şunu anladım hangi pic kullanıyorsan onun datasheetini hatim etmen gerekiyor. Hakikatten  süpriz yumurta gibiler İçinden ne çıkacağı belirsiz. Şununda altını çizmek isterim özellikle eski üretim piclerin bir kısmı tımer0 kesmesi üretmiyor. Sebebi uyku modunda tımer0 modülüde kapanıyor. Ama extrem low power diye geçenlerde uyku modundan bağımsız çalışan tımer modülleri var. Böyle birşey yapmaya çalışan arkadaşların dikkatine. Kullandığınız pic in datasheet lerinde mutlaka sleep paragrafını okuyun:-)