PIC16F877 + DHT22

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.