Ez így ránézésre jónak tűnik, a minimum időket elvileg hoznia kell ( ha jól van beállítva és az 1us tényleg annyi ! ) ! Szkóppal mit látsz? A mester kiadja GND-t min. 480 us-ig ? Utána a felhúzóellenállás visszaviszi a szintet '1'-re ? DS nem húzza újra nullára? Ha nem, akkor DS kuka!
A mutatott kódban csak a függvényeid vannak, a main nincs !

Jelen pillanatban csak ez a két rutin fut le.

De ahogy fentebb is láthatod, megakasztom a futást, hogy lássam van e visszajelzés.
Nincs, tehát a 480us alatt nem húzza a DQ lábat alacsony szintre a DS.
Az időzítés szerintem jó, bár lehet benne hiba, de ezt kétlem, többször átnyálaztam az osztásokat és elvileg annyi amennyinek kell lennie.
Az 1us és az 1ms-is.
16MHz-es kristály 4xPLL bekapcsolva 64MHz-n fut a 18F46K22.
Ez a max amit tud.
Ez leosztva: 1/(64000000/4) == 0.0000000625
Tehát egy ciklus idő 0.0000000625.
Ezt felszorzom 16-al és az eredmény 0.000001 vagy is 1us.
Vagy is Nop() * 16 == 1us
Illetve (Nop() * 16)*1000 = 1ms

Elvileg az időzítés tökéletes.
Az, hogy a DS18B20 hibás lenne kétlem, mert a szimulátorban sem működik és ott nem lehet kidögleszteni az alkatrészt
Szóval szimulálom is és élesben is tesztelem, de amíg szimulátorban nem lesz jó, addig élőben sem sajnos.

Szóval megint csak leblokkoltam, hogy miért nem jó.
A PIC beállítása is szerintem jó, más perifériával nem volt még gondom pedig egy két kényesebb időzítés már kellett, és ment az összes, de ez kifog rajtam és roppant mód szúrja a csőröm
Skópom itt Pesten nincs sajnos, így azzal mérni nem tudok.

Vélemény?

Mennyire sürgős? Ma nem érek rá, de ha holnap elküldöd a hex-et ( config bitekkel !), akkor megnézem neked szkóppal, hogy mi újság !?

De a Proteusban nem tudod szkóppal megnézni ?!

Persze, simán van időm rá, hiszen ameddig nem működik, úgy sem tudok vele mit kezdeni.
Átlépek win-be és generálok egy hex-et, mert most debug módba vagyok.
Gondolom a program leakasztását vegyem ki belőle..?
A szenzor lekérdezését tegyem bele a főciklusba?
Tehát a while(1) futtassa a DS lekérdezését?

De megnéztem Proteus-ban is, és azt mutatja amit linkeltem képet az előző oldalon.
Abból meg elég nehéz kihámozni, vagy nem jól használom..

Megpróbálhatjuk a lekérdezést is, de csak estefelé leszek otthon próbára elvileg...!
Az első mindenképpen a jelenlét kell, hogy legyen !
Egyéni azonosítót adsz ki vagy általános lekérdezést használsz ?!

Szia!
A DS18B20 nagyon kényes a megszakításokra, így azokat le kell tiltani a konvertálás és kiolvasás idejére!

Nem a megszakításokra kényes, hanem az időzítésekre! Én csak az időzítések alatt szoktam letiltani , nem az összes, vele kapcsolatos művelet ideje alatt, mert így blokkolod a megszakításokat is !

Hát most először is, azt tapasztalom, hogy csináltam egy 100ms időnkénti szintváltást a C0-ás lábra.
És a képen is látszik, hogy valami nem kerek, mert hogy 100ms helyett 332.5ms-os idővel vált szintet a porton.
Valami nagyon nem jó, ha a Proteus-nak lehet hinni.
Mit rontok el mikor beállítom az 1us-t vagy az 1ms-t?
Itt vannak a comfig bitek beállításai:

Regiszterek:

És csatolom a hex fájlt is.

Azért ez nem biztos ! Assemblyben ez látszana, hogy nem "csak" 16-ot számol és kész, hanem közben ugrándozik, ami plussz idő ( de szimulátorban is mérhető az MPLAB-ban ) !


Ez meg pláne nem jó, mert min. 10 ms-ra jön ki, nem 1-re ( az előbb TCY*16 az 1 us lett volna, most megszorzod 10000-el, az szerinted mennyi lesz ?! ) !

Ne azt nézd.
Hanem ezt: Delay10KTCYx(16);
Itt van a delay gyári könyvtárából:

Ebből csinálok 1us-t, ha 16-al megszorzom, mivel a ciklus idő 0.00000000625.

Ez pedig az ms-ért felelős:


A lényeg, hogy ha 0.00000000625 egy ciklus idő akkor ezt fel kell szorozzam elsőnek 16-al ez ad 1us-t.
Ezt végül meg kell szorozzam ezerrel és akkor lesz 1ms, de ez most lényegtelen.

Ha a Delay10KTCYx();-el számolok, akkor ekképpen alakul.
1 Delay10KTCYx(1) == 10 000 vagy is == 0.00000000625*10 000 == 0,0000625 ezt fel kell még szorozzam 16-al == 0,001 vagy is 1ms.
Érted a számolásom?
Elvileg ennek jónak kellene lennie, bár már kételkedem benne, de a számolás tuti jó, de az elv lehet hibás.

Megnéztem Arduino-val egy DS18B20-at, rövid vezetékkel már 220usec resetre reagált:

A válaszok:

Köszi, de ezzel az adattal még én semmire nem megyek, mert nekem nem reagál.
Fogalmam nincs már, hogy miért és hol hibázok, annyira bele vagyok már keveredve mint macska a spárgába, nem látom a fától az erdőt, egyszóval káosz ül a fejembe
Durva..., elvileg minden jó és még sem jó, kell egy friss szem aki a szimultánban rá tud nézni.
Előző oldalra feltöltöttem a teljes projektet.
De felteszem a mostanit is. (C18 fordító kell hozzá)

ui: próbálgattam az időzítést kézzel állítgatni, lejjebb majd feljebb, hogy hátha, de semmi változás.

Na ez nem megy, ha te is érted, amit írtam ... ! Az OK, hogy 16-szor akarod meghívni, de akkor 16-szor kell leírni a Nop()-ot! Ha ciklusba teszed, akkor az inicializálás, az inkrementálás utáni vizsgálat mind-mind további utasítások, így nem 16 us lesz a 16-os ciklusod!


A 64 MHz-nek megfelelő TCY=0,0000000625 s és nem 0,00000000625 s, így a beállított értéked nem 1 ms, hanem 10 ms !

Szerintem értettem a számolásod, Te érted az enyémet ( írtad is, hogy 1000-el kell szorozni, akkor ne a Delay10KTCYx()-t használd ! ) ?!

Egyszerű a megoldás.
Először készíts egy mondjuk 1 perces számlálót, kapcsolgasd a LED-et 1 percenként, és mérd meg, hogy az 1 perc tényleg 1 perc-e. Amíg nincs egy normális időalapod, addig felesleges továbbmenned.
Ezután fogd az adatlapot, és indulj el az elejéről. Azt mondja, kell egy reset. Húzd le a lábat, várj 480uS-ot, aztán engedd el, várj még egy kicsit, hogy a láb tényleg magas legyen, majd kezd el figyelni, hogy van-e erre reakció, ha igen, világítson a LED. Csak ennyi legyen a programod, ne több. Ehhez 1 LED kell, más nem. Aztán mehetsz tovább. Felesleges belevágni a közepébe, ha még az 1uS se 1uS.
Nincs valami delay_ms függvény, hogy ne kelljen számolgatni?
Egyébként ha ennyire nem stimmel az időzítés, akkor még sincs megfelelően felkonfigurálva az a PLL, meg amit még fel kell.

Oksa értem, 1 nullával többet írtam.
Igazad van, nem 10000 hanem 1000 kell.
És igen további időveszteség, a többlet utasítás, de ennek bele kell férnie.
Este kipróbálom.

Kovidivi: este lépésről lépésre végig megyek megint..

Fisc mire van definiálva. Ezzel a konstanssal tudod megadni a delay* függvényeknek a rendszer órajel frekvenciáját.
PIC18F2550: 20 MHz, PLLDIV = 5, PLL, PLL postscalar = 2: 48MHz

Nos tutira az időzítéssel van gond.
Most ugyan már mutat valamit, de még nem az igazi.
Nem stabil az időzítés.
Van ötletetek, hogy a fentebb belinkelt kódok alapján, hogy tudok egy stabil késleltető rutint írni?

A baj az, hogy ha beállítom, hogy 1us meglegyen akkor jó lesz, de ha emelem mondjuk 50us-re a már megírt rutint akkor már elcsúszik az egész.
1 és 500us közt lehet akár 250us eltérés is, ms-nél is van csúszás.
Ez mondjuk már PIC-es téma, lehet ott kellene folytatni.

Akkor már látod a hibát, azt kellene első körben kijavítani és ha majd a "tuti" időzítés mellett sem jó, akkor kell tovább vizsgálódni !

Igen, értem amit írtál, de nem tehetek 16*550 Nop()-ot amikor annyi kell.
Ha meg nem teszek, akkor megint csak ciklust kell használnom.
Ugyan ott vagyok..

Mi a megoldás?

16 * 550 = 8800 -->

Ez miért nem jó ?

Ja, hogy több függvénnyel hozzam össze.
Megnézem mit mutat, mert élesben nem megy sajnos.

Akövetkező akkor:
16*70 == 1120

Megcsinálhatod így is :

!

Jaja, megoldottam, de élesben nem megy a cucc.
Szimulátorban már pöpec, de élesben valami még nem kerek...
Kellene egy oszcillátor, hogy meg tudjam mérni mennyi is az annyi, fene...

Szimulátorban már jól működik a dolog, de élesben sajnos nem.
És fingom nincs miért.
A jelenléti jel is megérkezik szimulátorban is, igaz csak a második lefutáskor, de élesben egyáltalán nem jön visszajelzés a DS-től.
2 DS-em van itthon és mindegyik ugyan azt csinálja, vagy is, semmit.

Még mindig az időzítéssel lehet gond?
Már 100féle képen kipróbáltam az időzítéseket is, egyszerűen nem tudom rávenni, hogy végre élesben is működjön.
Lehet ki kell dobjam a kukába mert egy pocsék és brutál kényes egy alkatrész ez a DS18B20.

ui: a vezetékezés hossza mennyire problémás?
Kb. 10-15cm vezeték van a PIC és a DS közt.

Több helyen jól működik, hosszú kábelekkel is. Hogy hogyan, azt nem tudom, nem ismerem a C nyelvet.

100szor átnéztem mident, időzítéseket is elejétől a végéig, oda-vissza és semmi.
Szimulátorban frankón működik, de élesben meg sem moccan.
Hibás lehet mind a 2 szenzor?
Komolyan nem tudom már merre induljak tovább.

Tölts le egy kész Ds-es programot valahonnan, bármilyen chipre ami van otthon és probáld le a Ds-eket. (Ha AVR-ed is van küldhetek én is) Ha a Ds jó, tényleg lépésről lépésre írj programot. Ahogy írták, az időalapot ellenőrizheted leddel a valóságban, aztán már csak a hat parancs van... Működik az hosszú vezetékekkel is. Gondolom a 4.7k külső felhúzóellenállás ott van. Nem a Ds a programozás kancsendzöngája.

Szia!
Küldd át a hex-et, amit használsz és megnézem ,hogy "mit követ el" a programod !
A konfigurációs bitek legyenek benne a hex fájlban, mert úgy akarom beállítani, ahogy neked van !
Ha gyors vagy, akkor most ránézek !

Már ajánlottam, hogy készítsd egy 2 perces időzítőt LED-el, és mérd le, hogy mennyi is az a 2 perc. Megtetted? Mert akkor kiderülne végre, hogy sikerült-e felkonfigurálnod a PIC-ed.

pont: írtam már sokkal, bonyolultabbat is, de eddig ez bizonyul a leg nehezebbnek, időzítés szempontjából. LED villogás megvolt, 4.7k felhúzó megvan.

Kovidivi: igen, köszönöm, ez mindig alap, ha időzítéssel vacakolok, termesztésen megvolt a LED-es tesztelés és vissza ellenőrzés.

Nem először használom ezt a PIC-et és ezért nem volt egyértelmű, hogy most mi a bánat is van.
Bár az is igaz, hogy talán ennyire pontos időzítésre még nem is volt szükségem soha.

Kissi tegnap este kipróbálta az enyémről mintázott, saját próbapanelján a programot és őnála simán működik, a furcsa viszont az, hogy nálam még mindig nem működik
Lehet vettem 2 döglött DS-t.
Ez mondjuk mindent megmagyarázna.