PIC16F877 + DHT22

Už od rána se těším až to zkusím dát za delay, večer dám vědět :slight_smile:

Jak víš, že testuje nuly ? Myslím, že by ses měl pořádně podívat Ty. První dva dlouhé pulzy jsou 80us dlouhé. Odstup od sestupné hrany k jeho toggle NENÍ 120us, ale nějakých 32-33us. On totiž dílek, tedy těch 50us, je od jedné dlouhé čáry ke druhé. Ty krátké čárky jsou po 10us. V tomhle datagramu se nemůžeš dívat na to, kde je toggle, resp. jak daleko je od té které hrany - tady je to úplně jedno, protože :

  1. udělá toggle
  2. čeká na náběžnou hranu (to je while smyčka, ne přesně daný delay)
  3. počká 35us (to je přesně daný delay)
  4. přečte si stav pinu
  5. případě, že je pin high, tak počká na low (opět while smyčka)

Tím smyčka končí a jde na 1) nebo po 8. bitu vrátí hodnotu. Všimni si, že toggle dělá PŘED ČEKÁNÍM na náběžnou hranu, takže toggle = vstup do smyčky, následuje náběžná hrana a 35us po ní čte pin, jenže ve kterém je to místě nezjistíš, protože tam toggle NENÍ !!!. Místo, kde čte si můžeš jenom odpočítat a říct “tady někde se čte pin”. Ten high impulz pro 0 trvá cca 25us, pro 1 trvá asi 68us. Z toho plyne, že číst by měl cca 1 čárku za sestupnou hranou nuly, v případě jedničky zcela bezpečně cca v polovině pulzu.

Než něco napíšeš, měl by sis především pořádně prohlídnout program, projít datasheet, zkontrolovat, jestli jsi v datagramu pochopil správně dílky a pak to ještě jednou zkontrolovat.

Nech si ty osobní invektivy, jo (myslím tu poslední větu)? Od toho tu nejsme, abysme si nadávali. Už jsem tu jednou psal že z toho záznamu z pseudoanalyzéru nejsem moc chytrej.

Jo, to vím taky že nemá značku tam kde ji má mít. Když se něco ladí, tak se značky (jo, to je ten toggling) dělají proto, abysme viděli, ne proto aby se něco dopočítávalo, dělat značku před čekací smyčkou tedy jaksi postrádá význam.

Počkám až to změní a s čím pak přijde.

OK - připouštím, že jsem tu poslední větu trošku přehnal, nicméně - pokud datagramu 100% nerozumíš, tak se nemá smysl hádat do bezvědomí. Totéž platí u datasheetů a vlastně úplně u všeho…

V tom případě mi vysvětli, k čemu ty datasheety jsou ? Když vezmu datasheet třeba ke stabilizátoru 7805, tak se tam dočtu, že výstupní napětí je :
min. 4,8V, typ. 5V, max. 5,2V => 5V ±0,2V

To znamená, že je tam tedy kolik ? 2-48V (případně nějaké jiné) nebo 4,8-5,2V ? Úplně to samé platí pro časy uvedené v datasheetu DHT22. 0 je 22-30us a přes to vlak nejede.

To je jen tvůj pocit, že tomu nerozumím. Taky mám různé pocity, ale jelikož jsem se nepřišel hádat, nechávám je stranou.

Máš pravdu v tom že výrobce neuvádí rozsahy parametrů pro nic za nic, ale myslel jsem to tak, že rozhodně není optimální pohybovat se na jejich hranicích (35µs je taková hranice, střed je jinde když si trochu započítáš. Chápu že kód má nějakou režii, a tu bych právě pro zajímavost rád viděl na tom záznamu*), ale spíš myslet dopředu a připravit se na víc eventualit (včetně např. vadného čidla, jak jsi správně podotkl s těmi timeouty, nebo třeba rušení na lince apod). K tomu jako jeden z prostředků mimochodem slouží i ten kontrolní součet co čidlo posílá na konci, jistě to nemusím probírat dopodrobna (stejně tak jako nekritizuju jeho nevyužití v kódu, to je jeho rozhodnutí jestli součet využije nebo ne, a jeho případná rizika. Já jen zmiňuju že tu ta možnost je, nemá to žádný emocionální ani jiný podtext, takže bych byl nerad, kdyby si ho tam někdo svévolně dosazoval).

Rozhodně nemůžeš popřít že jednoduchá úprava kódu za účelem zpřehlednění záznamu je krok dopředu (a předtím jsem hovořil právě jen a pouze o tom, jak ten záznam vypadá - vím proč tak vypadá, nemusíš mi to vysvětlovat), cílem teď je aby vypadal líp a víc tak vypovídal o tom, co se přesně děje. Pak totiž zřejmě vyplavou na povrch další věci, které teď nejsou moc dobře vidět.


Nevím co umožňuje ten PK analyzér, ale jestli to dobře chápu* tak stejně máme malou vzorkovací frekvenci, jeden systick toho PICu je 500ns aktuálně.

**Neplést si zdvořilost s blbostí prosím, a to obecně všude, ne jen tady… Děkuji.

Tak jsem dal ten toogle hned za to čekání a podle mě to tak má být.
Mělo by to být 0000000101101001 což je 361/10=36,1% to by snad mohla být vlhkost v pokoji.
Ale na GLCD mi to zobrazuje hodnotu 257 a nebo 256, ještě jsem ji nedělil 10.
Což mě napadá, že že 256 je vlastně první byte posunutý o 8 doleva ale nevím, proč tam je jako druhý byte 0 a nebo 0.

Pro to spojení byte používám

	vlhkost = (RH_byte1 << 8 )| RH_byte2; 

Což si myslím, že by mělo fungovat.
Když dám zobrazit na druhém řádku číslo měření a na 6. vlhkost tak tam mám těch 257 nebo 256.
Pokud tam k přidám zobrazení jednotlivých byte vlhkosti na 4. a 5. řádek, tak mi to z nějákého důvodu na číslu měření napíše 8225, na vlhkosti 8224 a na těch jednotlivých byte vlhkosti - Byte1 0 a na Byte2 0 nebo 1ku.
Nechápu proč, číslo měření by mělo jít od nuly nahoru a ne v prvním cyklu hned na 8225.

Myslím,že tak jak jsem to popsal, tak to nemůže nikdo pochopit. Pro jistotu tu dám zase kód při kterým to vypisuje pouze číslo měření a vlhkost.

[code]// DHT22 knihovna
unsigned char Check;

void StartSignal()
{
TRISA = 0b00000000; //PORTA je výstup
RA0 = 0; //RA0 jde do 0 = startovacísignál
__delay_ms(18);//18
RA0 = 1; //RA0 se vrací do 1
__delay_us(30);
TRISA = 0b11111111; //PORTA je vstupní
}

void CheckResponse()
{
Check = 0;
__delay_us(40);
if (RA0 == 0)
{
__delay_us(80);//80
if (RA0 == 1)
Check = 1;
__delay_us(40);//40
}
}
int ReadData()
{
int i=0, j;
for(j = 0; j < 8; j++)
{
i = 0;
while(RA0 == 0); //Čeká dokud je RA0 v 0
__delay_us(35);//30 hranice mezi log 0 a log 1
RC6 = ~RC6;
if(RA0 == 1) //Zkouší, zda je RA0 po uplynulé době v 1 čí 0
{
i|= (1 << (7 - j)); //Nastaví bit do 1
while(RA0 == 1); //Čeká dokud je RA0 v 1
}
}
return i;
}

void main(void)
{
PSPIE = 0;
PSPMODE = 0;
ADCON1 = 7;
TRISA = 0b00000000;
TRISB = 0b00000000;
TRISC = 0b00000000;
TRISD = 0b00000000;

   GLCD_Init(); 
   __delay_ms(100); 
   GLCD_ClrScr(); 

   int i = 0; 
   char text1[16]; 
   char text2[16];
   char text3[16]; 
   char text4[16]; 
   char text5[16];
   char text6[20]; 

   GLCD_ClrScr(); 
       
     int T_byte1, T_byte2, RH_byte1, RH_byte2; 
 int Temp, RH, Sum ; 

   TRISA = 0b00000000;    //RA0 jako vstup 
   TRISC = 0b00000000; 
	int a = 0; 

  unsigned int teplota =  0;
  unsigned int vlhkost =  0;

while(1) 
{     
  RH_byte1 = 0; 
  RH_byte2 = 0; 
  T_byte1 = 0; 
  T_byte2 = 0; 
  teplota = 0; 
  vlhkost = 0;       



	StartSignal(); 
	CheckResponse();

	RH_byte1 = ReadData(); 
	RH_byte2 = ReadData(); 
    //T_byte1 = ReadData(); 
    //T_byte2 = ReadData(); 
    //Sum = ReadData(); 

vlhkost = (RH_byte1 << 8 )| RH_byte2; 

	GLCD_ClrScr(); 

  sprintf(text5,"Mereni: %d                ",a); 
  GLCD_text(0, 1,text5 );
  /*sprintf(text1,"Byte 1: %d               ",RH_byte1); 
  GLCD_text(0, 3,text1 ); 
  sprintf(text2,"Byte 2: %d               ",RH_byte2); 
  GLCD_text(0, 4,text2 ); */

  sprintf(text6,"Vlhkost:%d             ",vlhkost); 
  GLCD_text(0, 5,text6 );

a++;

  RC7 = 1; 
  __delay_ms(500); 
  RC7 = 0; 
  __delay_ms(500); 

}//end while(1)
}//end main [/code]

Se divím, že jste mě ještě neposlali někam :slight_smile:

To je to co už jsem jednou psal - vyčteš 16 bitů, čidlo si vesele posílá dál, ale ty nepočkáš až „dokecá” a hned to tam pošleš znova, takže pak odchytáváš blbosti.

Aha kecám, máš na konci dvě půlsekundy, ty jsem přehlídnul.

Dej asi i ten záznam radši, jestli máš…

Odchytávat bordel přece nemůžu, než se provedou všechny ty sprintf, zobrazení a ještě tam mám delay na konci, tak to čidlo už má dávno dovysíláno.

Jj vím, vidím, už jsem psal. To víš, někteří nemají monitor s PIVOTem, a navíc si neberu pokaždý brejle :smiley:

Záznam? Co tím myslíš, video jak to jede?

Já tenhle analyzer neznám (mimochodem - není ten analyzer sw funkce programátoru ?), používám Saelae, ale co v datagramu vidím, tak podle posunu některých náběžných a sestupných hran vůči těm malým dílkům (10us), tak bych řekl, že má vzorkovací frekvenci 1 možná 2 MHz, což by odpovídalo 1us nebo 500ns. Pro tenhle průběh je to vzorkovací kmitočet dostačující. Ale třeba na snímání komunikace s některými LCD, kde je minimální šířka impulzu 1us už by to nestačilo.

JJ, je to dělaný přes programátor PICkit2. Klon Saelae už je na cestěněkde,ale bude to trvat.
Sample rate mám 250 kHz.

B0sc0:

  1. Texty máš nadefinovaný krátký a funkcemi sprintf píšeš i za pozice vyhrazené pro text.

Například :

[code] char text5[16];
.
.
.

  sprintf(text5,"Mereni: %d                ",a);[/code]

Jenže řetězec "Mereni: %d " má 24 znaků + délka textu hodnoty proměnné a + ukončovací 0 => tedy minimálně 26 znaků.

Nadefinuj jenom jeden řetězec a klidně ho po vytisknutí na LCD přepisuj.

[code] char text[64];
.
.
.

  sprintf(text,"Mereni: %d                ",a);
  GLCD_text(0, 1,text);
  sprintf(text,"Vlhkost:%d             ",vlhkost);
  GLCD_text(0, 5,text);[/code]
   vlhkost = (RH_byte1 << 8 )| RH_byte2; 

by chodit mělo, a pokud ne, zkus tam místo toho dát toto :

   vlhkost = (RH_byte1 * 256) + RH_byte2; 

P.S.: Pokud vidím snahu, tak proč bych nepomohl, když můžu.

Video ne, řekl bych, že měl na mysli datagram z PK analyzátoru.

Analyzátor je na cestě, donde cca do měsíce. Takže pak už to bude trošku víc profi. Na to moje domácí bastlení mi zatím stačil ten PICkit. Jinak díky za moře rad. Ty poslední zkusím dneska večer :slight_smile:

Tak jsem to zpravil podle posledních rad. Bohužel mám asi podezdření, že to špatně vyčítá, jelikož to vyčte a zobrazí následující:

Byte 1: 1
Byte 2: 1
Vlhkost: 257

a nebo

Byte 1: 1
Byte 2: 0
Vlhkost: 256

což ten výpočet funguje dobře, ale to vyčítání asi ne.
První byt by měl být 1, ale druhý něco okolo 105.

Asi to teď dám k ledu, nějak mi nejde rozchodit datalogger, počkám na ten profesionálnější alespoň budou pořádný průběhy.

Tak ještě zkus prodloužit ten delay třeba na 40 us. Teoreticky můžeš až na 60, ale musíš se stihnout vrátit na začátek smyčky ještě před náběžnou hranou bitu …

Teď si tedy hrajujes tím delay. Zkusil jsem ho zakomentovat a stejně mi to píše:
Byte 1: 1
Byte 2: 1
Vlhkost: 257

ale předpokládal bych, že by to mělo vypsat maximální hodnotu když budou všechny bity v jedničce 1111111111111111 = 65535.
Nemůže být chyba v

       i|= (1 << (7 - j));  //Nastaví bit do 1 

já tomu řádku teda vůbec radši nerozumím :slight_smile:

No možní rozumím, on jedničku vepíše do pozice (7 - j) a pak to jako přepíše i? Pochopil jsem to správně

Delay musíš nechat, ten je tam k tomu abys vzorkoval ten vstupující bit na správným místě, ale zkus ho prodloužit na těch 50, 60 cca (klidně i postupně nadvakrát).

Ten řádek je bitovej posun, nasouváš jedničku na určený místo, akorát mě tak dochází že to by vlastně mohl bejt ten problém. Jednak podle poslední verze programu nenasouváš nuly (neposouváš prázdné pozice bitů), takže nebudou vycházet pozice těch bitů oproti podobě vstupujícího signálu, a druhak se nemusí v každým průchodu cyklem posouvat o ‘i’, ale jen o jednu.