Problém s DS18B20, simuláciou v Proteus 8.6 a ATMEGA88PA-PU

Dobry den,

prosim Vas o viac rad, ktore maju suvis s teplotnym snimacom DS18B20, resp. DS18S20. Snad nevadi, ze to pisem v jednej teme.

  1. Mam kupene dva snimace DS18B20, ktore, ked zapojim podla manualu, VDD na 5V, GND na zem, a DQ cez odpor 4k7 na 5V, tak mi snimac zdroj skratuje a zacane sa prehrievat - rychlo som to vytiahol z kontaktného pola - zdroj mam s nastavitelnym prudom, ktory signalizoval pretazenie. Viete prosim poradit, co to moze byt? Stretli ste sa s niecim takym? Som z toho zufaly :confused: Ked zapojim snimac DS18S20, tak ten ma odber cca 0,01A - ampermeter na zdroji.

  2. Simulacia komunikacie so sminacom v Proteus 8.6 SP2. Program pre ATMEGA88PA-PU robim v jazyku C v Atmel Studio 6.2. Pouzivam externy krystal 14,7456MHz. Zahada je, ze simulacia pre displej, komunikaciu cez UART-USB s PC mi funguju bez problemov. Ale, komunikacia s DS18B20 mi nefunguje vôbec. Mam pocit, ze problémom je s casom vo funkcii _delay_ms() / _delay_us(). Na jeden PIN som pripojil LED a nastavil jej cas blikania 1000 ms cez _delay_ms(). Blika 10x pomalsie. Ked som v Proteus v nastaveni CPU nastavil frekvenciu 10x vacsiu, t.j. 147456000, tak LED uz v simulacii blikala v 1s intervale, ale zase prestal fungovat displej a UART komunikacia. Co mozem robit zle? Zaujimave je, ze ked program nahram do CPU, a spustim CPU, tak LED blika normalne (1s interval) a aj displej funguje, len mi nejde komunikacia so snimacom DS18S20 (snimace DS18B20 pouzit nemozem - bod 1). Viete mi s tym niekto prosim pomoct? Co je potrebne v Proteuse nastavit?

  3. Komunikacia 1-wire. Viete prosim poradit nejaku funkcnu kniznicu, ktoru mate 100% vyskusanu? Hladam uz velmi dlho, nasiel som ich uz par, ale problem je, ze mne nic nefunguje. Vsetky, co som nasiel, boli na frekvencii 1MHz, alebo 8MHz, ale nie na 14,7456MHz, ktoru pouzivam ja - dobra na komunikaciu s PC. Chcel by som skusit naprogramovat sam tuto kniznicu, ale ked neviem ci mam funkcne snimace a nejde mi ani simulacia, tak je tazko experimentovat. Rozmyslal som nad casovanim cez TIMER, nakolko cez _delay_us() CPU zbytocne vykonava prazne slucky. Aj ked teraz rozmyslam, ci ma tych par usetrenych ms vyznam a ci by to vôbec slo. Aky je Vas nazor? Frekvenciu by som musem dat 16MHZ, aby jeden cyklus bol celych x us, pri 14,7456MHz vychadzali desatinne miesta a bolo by to nepresne…

Moj zamer s DS18B20. Pouzit by som ich chcel viac, cez 10 snimacov na jednej kominukacii cez externe napajanie - 3-zilovy tieneny kabel. Zatial pre sledovanie stavu teplot v kotolni a nasledne posielanie udajov cez UART-USB (virtualny COM) do PC. Nasiel som niektore kniznice, ktore hladaju snimace na 1-wire komunikacii, len simulaciou to neviem odskusat (bod 2) a v realne zial tiez (bod 1). Ale, nemalo by tomu vadit, ak by bol zatial len jeden snimac na zbernici?

Ak mi budete vediet pomoct, poprípade ma usmernit budem Vam velmi vdacny. Trapim sa s tym po troske uz asi 2 tyzdne a neviem sa pohnut k nejakému funkcnemu rieseniu. Dakujem vsetkym za ochotu.

Ahoj. Hoď bobek na simulátor, to je cesta úplně k ničemu. Kup si tohle a odlaď to s tím v reálným světě. Využít se to dá nejen na Dallas sběrnici.

První rada zní - začni postupně po částech a nesnaž se rozchodit všechno najednou. Nejdřív začni displejem nebo UARTem, abys byl schopný si nějak zobrazit, co se vlastně v procesoru děje. A teďka ke Tvým dotazům :

  1. Pokud se čidla chovají tak, jak jsi popsal, pak jsou obě DS18B20 v křemíkovém nebi. Oba typy čidel mají shodné zapojení a i shodnou komunikaci. V programu se jenom různě dekódují data.

  2. Buď jsi ponechal naprogramovanou pojistku CKDIV8 nebo (a to je pravděpodobnější) Proteus nestíhá. Proteus je šikovná věcička a ladím na něm spoustu věcí ještě před vlastní stavbou prototypu, ale nespoléhej na něj slepě a sleduj, co to píše za hlášky. Při krystalu 14,75 MHz už asi nebude simulovat v reálém čase (napíše Ti, že kvůli vysokému vytížení procesoru simulace neběží v reálném čase) a pak se Ti klidně může stát, že LEDka bliká 10x pomaleji, ale na funkčnost programu jako takovou (ani na výsledek simulace) to vliv nemá - jen na její rychlost. Při simulacích v Proteu do procesorů vkládám přímo přeložený .hex soubor, abych měl jistotu, že v mcu simuluju to, co mi přeloží překladač (dám vložit zdrojový soubor a místo *.c tam dám . a vyberu můj přeložený .hex soubor). Při úprave programu pak jenom zastavíš simulaci a spustíš ji znovu, aby se Ti .hex soubor v paměti aktualizoval. Jinak 1-wire Proteus umí, takže se dá předpokládat, že pokud to nechodí v Proteu, nebude to chodit ani v reálu. Na druhou stranu, co Ti brání zapíchnout procesor do kontaktního pole, přidat k němu čidlo a testovat zároveň v reálu …

  3. Co se knihovny týká, tak tam bych Ti poradil jenom “začni postupně”. Nastav procesor na IntRC 1 nebo 8 MHz a rozhýbej komunikaci displeje, UARTem a nakonec i s čidlem (klidně použij nějakou knihovnu, kterou jsi někde stahnul). Pokud budeš po UARTu posílat jenom přečtenou teploty (2 byty co přečteš z čisla), tak ani pro UART nemusíš používat krystal. Pak přehoď procesor na ten Tvůj krystal a postupně rozběhni displej a UART. Jakmile budeš schopný zobrazovat, co potřebuješ, můžeš upravit knihovnu (případně napsat svojí). Pokud by ses rozhodl napsat si knihovnu sám, doporučil bych Ti oddělit od sebe teploměry a samotnou 1-wire komunikaci.

V případě 1-wire komunikace jde hlavně o to, vyladit funkci delay tak, aby čekala, jak dlouho má. Navíc je potřeba, aby během zápisu nebo čtení jednoho bitu bylo zakázáno přerušení (je to max. 120us). Já jsem si knihovnu pro 1-wire psal sám (v assembleru) a umí i prohledat sběrnici a udělat seznam připojených 1-wire zařízení a následně s nimi komunikovat. Vlastní komunikace už pak používá tuto knihovnu k zápisu/čtení dat do/z 1-wire sběrnice, takže teploměry jsou vlastně knihovna, používající 1-wire knihovnu. Používám i vlastní Wait knihovnu a změnu kmitočtu procesoru řeším úpravou 3 ze 4 delay funkcí Wait1us, Wait2us, Wait10us a Wait100us tak, aby trvaly požadovanou dobu s co nejmenší odchylkou. Wait100us se už pak skládá z 10 volání Wait10us.

Dakujem Vam obom za reakciu.

Odpoved pre Billy Bob Bean:
Prikladam subor pre Proteus + hex subor pre CPU a rovno aj zdrojak s knihovnami pre LCD a 1-wire komunikaciu. Ten logicky analizator vypada zaujimavo, rozmyslal som uz dlhsie nad osciloskopom, ale odradzala ma jeho cena a zase nerad kupujem lacne “hovadinky”. Len otazka: Je potrebne k tomu asi aj kupit “Měřící háčky pro logický analyzátor”, ano? Predpokladam, ze nie su dodane spolu s analizatorom, aspon som si nevsimol, ze by to tam pisali. A co vsetko je s nim mozne sledovat? Vsetky komunikacie, poprípade aj striedu PWR regulacie?

Odpoved pre Balů:
Ano, presne tak som postupoval. LCD displej mam uz dlho odladeny a vyuzivam ho aj realne na CPU. Mam uz aj odladenu komunikaciu medzi CPU, uz aj medzi CPU a PC cez vitrualny COM port (prevodnik UART cez USB). Toto vsetko mi uz pekne funguje. Jedine, co mi teraz robi vrasky na cele su tieto snimace teploty a komunikacia 1-wire.

  1. To si ma nepotesil, ale cakal som nejaku taku odpoved. Je mozne, ze som ich mohol poskodit nejak ja? Na co si pri nich davat pozor? Boli uplne nove, tak preto som v rozpakoch. Predpokladam, ze by sa nemalo stat, aby mali zamenene vyvody. Moze ich poskodit, ked ich zapojim napríklad len na napajanie, bez pripojeného DQ pinu? Alebo, ak mam v programe nastaveny PIN pre 1-wire komunikaciu na CPU v logickej 0? Teraz som si uvedomil, ze na zaciatku, ked nastavujem piny na vstupne a vystupne (DDRB) tak vsetky piny nulujem (PORTB = 0x00;). Neprekaza to snimacom? Nemal by som PINB0 nastavit hned na log 1? Daju sa nejak tieto snimace premerat merakom?

  2. Dakujeem :slight_smile: Uhadol si, zabudol som prestavit CKDIV8 na 1. Uz LED lepsie blika (aj ked nie 1s intervale), ale 1-wire komunikacia aj tak nejde :confused: Teraz mi funkcia pre hladanie snimacov OWFirst() vrati hodnotu -3 OW_BADWIRE, predtým mi vratila hodnotu -1 OW_NOPRESENCE - v programe Proteus. V reali mi to funguje tak, ze ak pripojim odpor 4k7 na PINB0 a na +5V, tak bez alebo s cidlom mi vrati hodnotu -1 OW_NOPRESENCE. Ked odpor dam prec a necham nezapojeny PINB0, tak vypise -3 OW_BADWIRE - co je spravne. Len sa este pokusit donutit CPU najst snimace na zbernici. Predpokladam, ze ak hladam unikatny kod snimaca a je pouzity len jeden snimac na zbernici, tak by mu to nemalo vadit, ano?
    Hlasku, ze by Proteus nestihal,som si nevsimol. Ak je to v Message, tak vypise toto:

PROSPICE 8.04.00 (Build 21720) (C) Labcenter Electronics 1993-2017. Loaded netlist 'C:\Users\tomas\AppData\Local\Temp\LISA9133.SDF' for design 'Teploty.pdsprj' AVR Release 8.3SP0 build 22019 for ATMEGA88P. [U1] Loading HEX file 'C:\Users\tomas\OneDrive\Atmel Studio\6.2\Teploty\Teploty\Debug\Teploty.hex'. [U1] Read total of 2834 bytes from file 'C:\Users\tomas\OneDrive\Atmel Studio\6.2\Teploty\Teploty\Debug\Teploty.hex'. [U1] Controller received command whilst busy. [LCD2]
Do Proteusu, tak ako mi aj radis, davam priamo hex subor, ktory mi vygeneruje AVR Studio - priamo cesta do projektu v ARV Studiu. Tak je to najjednoduchsie, presne ako pises :slight_smile:
Testovanie v reale mi v podstate brani asi len to, ze nemam istotu, ci su snimace vporiadku. Budem musiet kupit nove, poprípade zatial skusim len s DS18S20, snad ten je dobry.

  1. Nad tymto riesenim zacinam vazne uvazovat. Asi si komplikujem zivot sam, ze to chcem rovno rozchodit s krystalom 14,7456MHz. Skusim to teda postupne, najprv vyskusam nejake funkcne riesenie s 1MHz alebo 8MHz, aj ked len s jednym snimacom a snad si aspon tak overim funkcnost snimacov a funkcie na posielanie bitov / bytov. V podstate, asi to je to najhlavnejsie a potom by som uz snad mohol prist na to, ako hladat adresy snimacov a potom ich budem chciet aj prestavit na 9 bitove rozlisenie - to zatial neviem ako presne, ale k tomu je este daleka cesta, to ma cas.

Skoda, ze si tu knihovnu pisal pomocou assemblera, ale tak snad to casom rozchodim. Nasiel som jednu stranku, kde boli pisane odporucane casy pre 1-wire komunikaciu. Skusim sa do nich nejak dostat. Rozmyslam, ci by mi pomohol pri tom timer. Nastavim casovanie tak, aby jedna perioda trvala 1 us (frekvencia 1MHz a preddelicka 1). TCNTn zasobnik pred zavolanim delay funkcie vynulujem, a hned po delay vypisem TCNTn zasobnik na displej a tak by som mohol zistit, kolko v skotucnosti trva. Dava to zmysel? :wink: A to zakazanie preruseni som uz tiez niekde spozoroval a dava to zmysel, darmo by som komunikoval so snimacom, ked by ma zrusilo prerusenie :slight_smile: Ale zatial prerusenia nepovolujem.

Este raz Vam velmi pekne dakujem za Vasu ochotu pomoct.
Teploty.zip (19.7 KB)
Teploty.zip (286 KB)

Jenom poznámka ke kódu.
Do hlavního programu se neinkludují soubory “.c" nýbrž ".h”.

Pokud muzu doporucit analyzator tak asi: ebay.com/itm/24MHz-8CH-USB-L … SwPCVYBD2b

Ten z Pandatronu nema smysl uz jen diky te cene. Jestli myslite, ze je kvalitnejsi tak se pletete, mam oba a ten z Pandatronu je z roku 2014 - 2015 a uz nefunguje. po roce zacaly oxidovat pajene spoje ( pravdepodobne pouzili ageresivni tavidlo), neni NoClean jako noClean. Ale oba maji neco spolecneho porad je to klon Saleae a jsou osazeny totoznym HW. Takze rozdil jenom v krabicce :astonished:). U te cinske je aspon samolepka popisujici pinout.

Můžu vřele doporučit analyzátor, na který posílal odkaz pechyx. Mám ho také, také z Číny, akorát ne přes Ebay. Co se háčků týká, je to šikovná věc. Třeba tyhle : ebay.com/itm/New-Test-Hook-C … 67-oocFhUA

Tenhle logický analyzátor mám (i ty háčky jsem si k němu pořídil) a jsem s ním maximálně spokojený.

Včera večer jsem ještě koukal na ten program, cos posílal. Schema se mi nepodařilo otevřít (mám trošku starší verzi toho Protea), tak jsem si zapojení musel udělat podle programu. Máš pravdu v tom, že Proteus s tím zatím žádný rychlostní problém nemá. V messages by to byly žluté trojúhelníky s vykřičníkem. Na displej mi to vypisuje “-1 -1 0.0”. Knihovna mi připadá psaná poněkud divoce. Obzvlášť některé ty výpočty v returnech. To, že se dá napsat kontrola pinu i rozhodováním do jedné řádky ještě neznamená, že je to nejlepší způsob pro optimalizaci kódu. Tady přichází na řadu právě znalosti assembleru, aby člověk pomohl překladači napsat program co nejefektivnější a nejkratší (tím i nejrychlejší). Na téma optimalizace překladu už jsme tady debatovali jinde. Uváděl jsem i příklady překladu jedné věci zapsané různým způsobem. Ale to jsem trochu odbočil. Zkusím zjistit, kde by mohl být problém a uvidíme. Jinak virtuální logický analyzátor si v Proteu můžeš přihodit do schématu a uvidíš, co se tam děje. Nemá sice analýzu průběhů, ale uvidíš, co tam leze za obdélníky. Podobně můžeš použít i virtuální osciloskop.

Jinak použití timeru pro takhle krátké časy (jednotky až desítky us) nemá smysl. 1us při 1 MHz je 1 jednotaktová instrukce - a jsme zase u toho mít alespoň představu, jaké instrukce mcu používá a jak dlouho trvají = assembler, resp. instrukční sada.

Tak jsem koukal a koumal a zjistil jsem následující věci :

  1. Definuješ jednu hodnotu (konkrétně kmitočet procesoru) hned na několika místech nebo dokonce používáš přímo číslo místo nadefinované konstanty. Tohle NIKDY nedělej !!! F_CPU Ti nadefunuje překladač, všude jinde číslo vyhoď a dej tam F_CPU.
  2. Pro kmitočet použij raději tvar 14745600.0 místo tvaru 14745600UL. Tvaru s UL překladač v určitých situacích nerozumí a musel bys stejný číslo definovat vícekrát. Použitím F_CPU na všech místech, kde něco počítáš z rychlosti procesoru jsem dosahnul toho, že na změnu rychlosti procesoru stačí přepsat jedno číslo v nastavení projektu.
  3. 1-wire knihovna má pravděpodobně problémy s časováním. Funguje pouze, když nastavíš a nadefinuješ frekvenci procesoru na 1 MHz. Na jiných kmitočtech se mi z ní nepodařilo nic dostat.
  4. Když už funguje, tak špatně přepočítává záporná čísla. Nebo je aspoň špatně přepočítává ten přílepek do funkce DS18B20_read_temp.

Ještě Ti zkusím odpovědět na Tvůj dotaz ohledně logického analyzátoru. SW k němu umí rozkódovat celkem dost komunikačních protokolů, u periodických signálů umí Ti napsat i kmitočet a střídu, takže pokud budeš potřebovat analyzovat nějaký PWM signál, tak se tyhle věci dozvíš.

Opat dakujem vsetkym za reakcie.

Odpoved pre AB:
Skusil som upravit #include “lcd.c” na #include “lcd.h” a #include “1wire.c” na #include “1wire.h” a Atmel Studio pri preklade vypisal 15 chyb. Napríklad: “undefined reference to `lcd_init’” a takto vypise vsetky pouzite funkcie z týchto kniznic :confused:

Odpoved pre pechyx a Balů - logicky analizator:
Dakujem Vam obom za podelenie sa s Vasimi skusenostami ohladne logického analizatora. Takze kupim tento, ktory mate aj Vy, ale kupil by som ho z aliexpressu, odtial som uz nieco kupil, z eBay este nikdy. Vybral som teda toto:
USB Logic Analyze 24M 8CH
Meracie haciky 10ks
Program k tomu logickemu analizatoru bude fungovat tento?:

https://www.saleae.com/downloads

Odpoved pre Balů:
Ak by ste chceli, mozem Vam upnut verziu Protea co mam ja.
No asi to veru nebude najlepsia kniznica ako sa mi na prvy pohlad zdala. Este som nasiel jednu, ale nestihol som ju vyskusat. Je to z anglickej stranky a autor k tomu napisal: “Displaying temperature from DS18B20 sensors at LCD 4x20, connection of LCD by wizard CodeVisionAVR. External XTAL 3.6864 MHz, DS18B20 connected at PB0, LCD 4x20 connected at PORTC, destination system ATmega162.” Davam ju do prilohy.
Tuto vetu som nepochopil: “To, že se dá napsat kontrola pinu i rozhodováním do jedné řádky ještě neznamená, že je to nejlepší způsob pro optimalizaci kódu.” Mysleli ste ju na kniznicu pre 1-wire kominukaciu, alebo na pouzitie mojej funkcie napr.: “ZmenD(2,0);”?
Ak by ste mi vedel dohladat, kde ste uvadzal tie priklady na optimalizovanie kodu, tak si ich rad precitam :slight_smile: Ja som to skusil trosku hladat, ale mate veeeela prispevkov :slight_smile:
Este prosim, ak viete zareagovat na ten bod 1 o moznosti poskodenia snimaca a nastavenia PINB0 hned na zaciatku programu do log. 1.

Dakujem krasne za Vasu pomoc.
my_ds18b20.zip (24.5 KB)

**Odpoved pre Balů: **
Kym som odpovedal a hladal log. analizator, tak ste mi stihli poslat novu reakciu :slight_smile: Dakujem.

  1. Ak som Vas spravne pochopil, tak by som tu frekvenciu mal definovat v nastaveni Atmel Studio priamo v projekte. Toto nastavenie som pred par dnami hladal, ale nemal som to takto vysvetlene. Snad som nasiel spravne miesto na definiciu frekvencie - prikladam obrazok. Teraz mam teda vsade vyhodit z definicie frekvenciu a nechat len toto? Doplnil som si tam aj komentar, aby som na to nezabudol :wink:

#ifndef F_CPU #define F_CPU // Definovat frekvenciu vo vlastnostiach projektu->Toolchain->AVR/GNU C Compiler->Symbols->Defined symbols->F_CPU=14745600.0 #endif
2. Dakujem za odskusanie kniznice, aspon viem, ze pri 1MHz funguje a tak by som si dokazal odskusat aspon ten jeden mozno funkcny snimac. Dnes to uz ale odskusat nestihnem :confused: Pokusim sa zajtra, poprípade cez vikend.
3. To zle dekodovanie by mi az tak nevadilo, ked som pozeral datasheet, tak podla toho by som si mohol zvladnut spravit spravne dekodovanie, dolezite je, aby som spravne precital tia dva byte s udajmi o teplote.

Vazim si, ze mi pomahate, dakujem.

Nedalo mi to a zkoumal jsem, proč ta knihovna nechodí při vyšších kmitočtech, když na čekání využívá delay.h. Nakonec jsem přišel na to, proč to tak je. Po resetu 1-wire sběrnice a po přečtení bitu nečeká na “dokončení přenosu”, ale pokračuje normálně dál. Při 1 MHz ten čas vypršel ještě před další komunikací, ale pokud byla rychlost vyšší, došlo k další komunikaci ještě před dokončením té předchozí. Knihovnu jsem opravil a odzkoušel až do 16MHz a čidlo to četlo OK. Neopravoval jsem ten převod záporných hodnot. Vyšší kmitočet už zase nešel přeložit kvůli nesmyslně počítaném delayi v knihovně LCD. Přikládám upravený projekt v Atmel Studiu 7. Pokud Ti to v AS6 nepůjde otevřít, tak si do svého projektu nakopíruj *.c a *.h soubory. To by mělo být v pohodě.

Do souboru Teploty.c jsem po startu přidal zobrazení F_CPU na displej. Přikládám i kopii obrazovky z testování, abys viděl, že to šlape. Na fotkách je i vidět, že to vrací nemysly :

  1. Nesedí teplota - má být -1,2, na displeji je jenom -1,1
  2. zobrazení teploty (-1,-1) - já vím - to už nedělá knihovna…

Také jsem upravil projekt, jak psal AB. V souborech je includováno pouze *.h a knihovny jsou v seznamu zdrojových souborů. Kde jsou a jak je připojíš máš na obrázcích. Je to jednodušší, než to složitě vysvětlovat.
PripojeniSouboruDoProjektu.zip (135 KB)
Teploty.zip (98.6 KB)
TeplotyFoto.zip (58.3 KB)

Ještě pár restů v odpovědích :

  1. Logický analyzátor - SW z odkazu je přesně ten, se kterým to spolupracuje.

  2. Poškozené snímače

  • ptal jsi se na přehozené piny. Nestává se to, i když nic není vyloučeno. Dostaly se mi do rukou LEDky, které vypadaly, že nefungují, ale nakonec se ukázalo, že byly opačně zapouzdřené, takže když jsem je na DPS zaletoval “obráceně”, tak fungovaly. Podařilo se mi DS18B20 přepólovat, prst jsem na něm neudržel, ale zvládnul to, takže pokud máš na zdroji proudovou ochranu (tu já neměl), tak v případě, že jsou přehozené vývody na pouzdře, budou snímače fungovat. Jak jsem psal - snímače se od sebe v ničem neliší. Komunikace (1-wire) je shodná - ostatně ta je shodná pro všechny 1-wire zařízení. Liší se jenom v tom, co mu říkáš a co čidlo odpovídá. Data se od sebe liší až v dekódování informací z čidla, kdy DS18B20 má pro desetinnou část teploty nejnižší 4 bity, DS18S20 jenom jeden.
  • druhá otázka se týkala možnosti poškození snímače při nezapojeném DQ. Tím snímač nepoškodíš.
  • třetí otázka - jestli jsi nemohl poničit čidlo při inicializaci procesoru - ani tady riziko zničení nehrozí. Piny procesoru jsou po resetu nastavené jako vstupní a bez zapnutých pull-up rezistorů, DQ pin je de-facto otevřený kolektor, takže jediná (čistě teoretická) možnost poškození by byla, kdyby byl pin jako výstupní, nastavený na log. 1 a čidlo by v tu chvíli komunikovalo. Jenže výstupní proud pinu procesoru není tak velký, aby to dokázal.
  1. Zápis a optimalizace kódu
    Tady jsem měl na mysli ty return příkazy knihovny, do Tvých funkcí jsem ani nekoukal. O optimalizaci kódu jsem na fóru cíleně nepsal, ale když jsme tady rozebírali C, flagy a možnosti zápisu/kontroly jednoho bitu (zde v tématu “C a flagy”), tak jsem tenkrát zkoušel různé překlady různých zápisů a v posledním příspěvku jsem se o tom zmiňoval. Proto ta zmínka o tom zápisu a optimalizaci.

**Odpoved pre Balů: **
Dakujem Vam veeeelmi pekne :wink: Funguje, aj simulacia, aj realne a uz konecne aj upravene zobrazovanie záporných teplot. :wink:
Este chcem skusit prist na to, ako poslat snimacu hodnotu do 5. byte CONFIGURATION REGISTER, aby som ho nastavil na 9 bitove rozlisenie. A neviem, ci snimac staci raz nastavit na 9 bitove rozlisenie, alebo ho treba vzdy po starte CPU nastavit? Ale myslim si ze len raz a snimac by si mal hodnotu ulozit. Ale to uz zajtra, reps. cez vikend.
A este jedna otazka ohladne CRC - je potrebne tu kontrolovat? Chcel by som vediet Vas nazor.

Dakujem Vam este raz za Vasu ochotu pomoc.

Není zač. Co a jak zapsat do konfiguračního registru i informaci o tom, jestli je nutné nastavovat čidlo po každém zapnutí v datasheetu je, takže to tam najdeš. Co se CRC týká, tak záleží jenom na Tobě, jestli potřebuješ ověřovat správnost dat. CRC určitě není nutné kontrolovat, pokud jenom čteš teplotu.

Ano, to bola len uvaha, co este potrebujem zvladnut a podarilo sa mi to na prvy krat :slight_smile: Este raz dakujem za pomoc :wink: