Fórum témák
» Több friss téma |
Kérek tiz percet és küldöm a progit ami nekem megy.
Köszönöm...
Eljutottam idáig (mellékelt fileok). Proteusban működik de a valóságban 1000 fok körüli értéket ír, és hiába melegítem a szenzort - nincs változás. A hozzászólás módosítva: Márc 26, 2013
Milyen frekin megy a pic? minimum 8MHz kell neki.
Szia
A 10. oldalon Bakman DS teszt.fcf filet keresd és ird árt a te programodra.
Még egy dolog, a DS szenzor adat lábát ugye 4,7K-val húztad fel?
Tedd fel a valós kapcsrajzot, mert ha így van bekötve, ahogy a proteusban, akkor az nem jó. (egy halom kondi hiányzik!)
Én is valami hardver hibára gondolok. 4 variáció mind ugyanaz az eredmény. 1039 cfok.
Így van megépítve próbapanelen ahogy feltettem... A scop a pic felőli jeleket elég szabályosnak mutatja viszont a DS felőliek elég hegyesek és szűk-rövid tetejűek, és mintha nem tudná rendesen lehúzni.
Szia!
Nekem a 4,7k helyett 3,3k-val volt jó. A Flow rendesen csak a 0 portokon szereti használni a ds-t pl B0.
C0-on próbálom. Akkor próbálom 3K3-al. Kondit hova kellene még tenni?
Gondolom a DS táp és GND közé egy 100nF. Vagy inkább egy 1µF elko?
Ha a tápod eléggé szűrt akkor elég a 100n is.
Ha hosszú a kábel, akkor 470n..1µF kerámia SMD-t tennék. A PIC-re is kell 100n ahágy láb van. A tápr IC-re is kell, be és kimenetre is nagyon közel. Lehet, hogy nem ettől van, de ez alap, enélkül rajzot se készít az ember.
A projectben be van állítva a 20MHz-es sebesség? A kvarcon van 22pF kondi kettő? Idézet: „A Flow rendesen csak a 0 portokon szereti használni a ds-t pl B0.” Annó tesztképpen minden lábra rápróbáltam, ment rendesen, kivéve MCLR.
A kábel 10cm a két próbapanel közötti.
A kondik a helyükön de a próbapanelen még átnézem őket hátha lebeg valami. 2db 15pF van a quarz-on. A táp egy labortáp 5v-os kimenete. Biztos valami baudrate gond lesz... Keresem.
kiskata, amit én kipróbálnék:
Watchdog tiltása a konfigurációban, kissebb sebesség (pl. 10 MHz).
A Proteus állománya, amivel modelleztem az áramkört.
Ezt meg is jegyeztem, ha esetleg kell ilyen sebesség.
Tök mindegy milyen sebességgel megy az Fosc, csak jól kell beállítani a projectben és állítólag van egy minimum, ami 8MHz. A DS nyílván nem ezzel a frekivel megy, csak a fordítónak kell a pontos időzítések kiszámításához.
A hozzászólás módosítva: Márc 26, 2013
Megnéztem a programodat is. Nem inicializálod rendesen az eszközt ill. a vonalat.
Kell egy oo_busreset, ez egyégként is kell kiolvasások előtt. Utána kell egy oo_scanbus, majd egy oo_get_devicecount, de talán nem is érdemes végigmenni, mert nagyon sok helyen hibás. Régebben feltettem egy példát, aztán kicsit variáltam is, hogy normálisan lehessen használni megszakításban. Ha megtalálom belinkelem de te is keresheted addig!
Idáig jutottam. Az eszköz ID-t ki tudom olvasni de a temp érték még mindig -254 értékkel tér vissza a get_temp után. Mármint a próbapanelen.
Nyilván az összeollózásnál rontottam el. Érdekes a szimulátroban jól működik. Brrrr. A hozzászólás módosítva: Márc 26, 2013
Megvan. Ebben minden lényeges lépés benne van, igaz kicsit szétbontva, hogy ne akassza meg a program futását 1 másodpercre a Flowcode csodálatos rutinja, hogy száradna le a keze...
Bővebben: Link
Üdv Mindenkinek!
Flowcode segítségével szeretnék egy kisebb programot összehozni egy PIC-be. Adott egy változó, ami egy számérték lehet 0 és 255 között. Számomra a fontos információt az jelentené, hogy ez a szám páros, vagy páratlan. Ha ez egy portról beolvasott érték lenne, akkor ok, figyelném az utolsó bitjét... Mi lenne a legegyszerűbb módja annak, hogy ezt egy másik változóban (ami lehetne logikai 1 vagy 0) megkapjam? A másik kérdésem is hasonló... Két egész szám hányadosának az egész részére lennék kíváncsi, egy harmadik változóban. Hogyan? Természetesen én vagyok a tapasztalatlan ezekben a kérdésekben, ezért a segítségért előre is köszönet... Üdv! fatti
Amit te keresel az a mod függvény.
x = 5 mod 2 (eredménye: 1) Ötben a kettő megvan kétszer, maradék egy. Tehát ha kettővel végzed el a műveletet és az eredmény egy, akkor a szám páratlan. Ha nulla, akkor páros. Pl: 255 mod 2 -> 1 268 mod 2 -> 0
Nagyon köszönöm. Tanulságos.
Több szenzornál más az eljárás a megszakításban? Skiprom helyett direktben kell meghívni a DS címét? A hozzászólás módosítva: Márc 26, 2013
Igen, ha több DS van, akkor ki kell deríteni a címüket és nem a Skiprom-al kell megszólítani az elkészülés vizsgálatakor az eszközöket, hanem a címeket beállítva, a most nem emlékszem melyik beépített paranccsal!
Eszerint a oo_busreset után kiadott konverzió-kérés (0x44) mindenkinek szól az bus-on?
Ezután pedig kinyerni egyesével kell az adatot... vagy a konverziókérést is egyesével kell kérnem külön külön a DS-ek től? Bocsánat hogy ilyen kis pimasz vagyok a sok kérdéssel Közben lepróbáltam a C0 és B0 portokon működik, de a C1 C2-n nem. A hozzászólás módosítva: Márc 26, 2013
A konverzió parancs mehet mindegyiknek egyszerre, de elvileg csak külön külön lehet őket vizsgálni, hogy készen vannak-e. Esetleg meg lehet oldani, hogy 1sec-et vársz és kiolvasod őket, mert a legrosszabb esetben 0,7sec alatt megvannak, de ez nem túl elegáns.
A címző utasítás a oo_read_device, amiben a MACH ROM parancs megy ki a detektált eszközök címevel, de nem tudom hogy a detektálás jól működik-e. Ha belenézel a kódjába, láthatod, hogy nem tudsz beadni neki címet, hanem a maga által detektált eszközök címeit tölti be attól függően, hogy melyikre hivatkoztál(0, 1 stb.). Sajnos több DS-el nem tudtam tesztelni és nem biztos, hogy az oo_read_device parancs illeszkedne a példámba. Helyette a MACH ROM (55h) parancsot kellene használni az egyedi címekkel. Még annyit, hogy a konvertálás elkészültét lehet, hogy ugyanúgy kell detektálni, mert ott csak a vonal olvasása programrész van, és valószínű mind egyszerre engedik el a vonalat, ha készen vannak, de ebben még nem vagyok biztos... A hozzászólás módosítva: Márc 26, 2013
Nagyon köszönöm a gyors segítséget! Üdv! fatti
|
Bejelentkezés
Hirdetés |