Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Honnan tudod, hogy előbb nem kapcsolja ki a LED-et, csak utána kapcsolja be? Ez a tesztrutin nem azt csinálja amit szeretnél szerintem! A LED mindenképpen ki fog gyúlni!
de ez még egyszerűbb:
A LED csak akkor éghet, ha a 7. bit H
igaz.
így már ok. A 1shot bitre 1- et jelez. Viszont a DONE bitre 0 -t converzió után. MAgyarul a SEND jó lehet mert a 1SHOT bitet 1 - be billenti. Viszont a RECEIVE is jó mert a vétel után BEJOVO_TEMP 0. bitje is 1 be áll ami azt jelzi hogy történik változás a vétel előtti állapothoz képest (BEJOVO_TEMP mindig nullázva van RECEIVE elején.). Akkor hogy a DONE nem áll egybe csak azt jelentheti hogy a START_CONVERT valahogy nemjó amellett hogy a SEND jó és a RECEIVE is. Hú ehez már késő van. Már zsibbadok.
Gyors átfutottam a fórumot, google barátomat is segítségül hívtam, de nem találtam meg amit kerestem, tehát kérdezek.
Mennyiben hiúsíthatja meg az égetést a monitor közelsége? Gyakorlatilag, most nálam kereszttűzben van a számítógép tápjával. Mellékeltem egy kis vázlatot, hogy hogyan. A "kitolt" cd-tálcával szemléltettem a tájolást, továbbá a számítógépen nincs rajta a burkolata sem. (azért van így, hogy a téli időszakban ne párásodjon le, ha nincs bekapcsolva huzamosabb ideig, mivel a rajzon is látható falak hidegfalak.) Azért kérdezek, ilyen egyszerűt, mert megépítettem 2 égetőt is. De nem tudok düllőre jutni. Az első a WPB18, terveztem neki nyákot, oly módon, hogy egyenesen az égető a portba dugható, ICSP-nek 10cm-es réz drótokat használtam. Az Oshonnak a programjával probáltam. 7407-es meghajtóIC-vel. PICnek pedig 16f876A-t is és 16f628-t is próbáltam. Másik programozónak az Oshon saját égetőjét építettem meg, ezt pontsávos próbanyákra. 7cm-es printer kábel, plusz szintén 10cm-es ICSP vezetékek, tömör rézből. 7404-es meghajtóIC-vel. Ugyanazokat a PIC-eket próbáltam égetni, mint a másik égetővel. Szintén az Oshon programjával. A programban mindig a meghajtóIC-nek megfelelő beállításokat futtattam, később már kísérleteztem is, hátha jó lesz. Az ICSP vezetékeket UTP-kábelből bányásztam. Külső tápot használtam mind a két esetben, 16v-ból nyertem ki 78xx-es stabkockákkal a megfelelő feszültséget. A tünetek mind a két esetben ugyanazok, olvasáskor 3FFF-et kapok, írás után, ha visszaolvasom szintén 3FFF-et ír ki. Teljes lefordított programmal nem próbáltam még, mindig 0100h-ik címre beírtam 1111-et, gondolom, ha ez így működik akkor rendes programmal is menni fog. Sajnálom, hogy egy egyszerű kérdésből ekkora problémát csinálok, de ha véletlen mégsem a monitor a vétkes, akkor vagy a számítógép portja a hibás, vagy el kellene gondolkodnom azon, hogy pályát tévesztettem. előre is köszönettel: Balázs. U.I.: Az ENIAC-os poén jó volt 
Jó úton haladsz! Próbáld ki, hogy az 1SHOT-ot nem állítod 1-be, majd ismét állítsd be. Ha a csekkolás követi az akciót, akkor az írás olvasás rendben van.
Ha ez megvan, akkor a konverziós parancs után tegyél be egy feltételes ciklust, amiből akkor lépj ki, és gyújtsd be a LED-et, amikor a DONE 1 lesz. Ha nem lép ki a ciklusból(LED sötét marad), akkor meg kell keresni miért! Valami ilyesmi kell majd az időzítések helyére:
az RST vonalat nem kezeltem le, a példában...
Egyszerűen nem.
Már kikapcsoltam a START_CONVERT és a READ_TEMP részeket is. Azok sem zavarnak. Csak a DS1620 beállítás részt vizsgálom. Csak annyit hogy a 1SHOT tényleg 1 lessz e ha azt állítom be. De sajnos mindig 1. Ha 0 - át küldök neki akkor is 1.
Idézet: „Mennyiben hiúsíthatja meg az égetést a monitor közelsége?” A gyors valasz: A mostani monitorok (ertsd 10 evnel nem oregebb...) mar eleg jo arnyekolassal birnak. Igy is van nyilvan valamennyi szorasuk, de ha rendelkeznek a megfelelo minositesekkel kicsi az eselye, hogy Csernobilkent viselkednek. A programozohoz vezeto kabeleknek nyilvan minel rovidebbnek kell lenniuk, hogy minel kevesebb zajt szedjenek ossze a kornyezetukbol, es az sem artalmas, ha csavart erparakat alkalmaz az ember (pl UTP Cat-5 vagy Cat-6 kabelek ereit). Ezenfelul az aramkornek megfelelo zajszuressel kell rendelkeznie, hogy a fellepo EMI-ket kiszurje. De ezen felul nem szabadna, hogy ez gondot okozzon velemenyem szerint.
En azt nem ertem ebben az egeszben, hogy Watt altal beidezett kodban a CLK-t alacsonyra allitjak, majd olvasas, majd magasra allitjak. A Te kododban pedig CLK-t magasra allitod, majd olvasas, majd alacsonyra allitod tehat epp az ellenkezoje - de lehet tevedek, epp csak ra pillantottam es ez szurt szemet.
Melyik kódot nézted mert volt már fent pár verzió.
A CLK a SENd és a RECEIVE rutinokban van először alacsonyra majd magasra állítva.
Én nem hinném, hogy a monitor bármit is befolyásolna. Mérd végig egy multiméterrel az áramkörödet valamelyik program hardverteszt menüpontjában. Ha a megfelelő feszültségek a megfelelő helyeken nem jelennek meg a teszt során, akkor annak meg kell keresni az okát. Akár még a printerport is lehet ludas, pl. lehet, hogy nem mindegy, milyen típusúra van állítva a BIOS-ban.
Tudom hogy ez így van ajánlva de akkor sem értem:
Hogy a fenébe kerül bele a BEJOVO_TEMP - be az érték?
Ha a DAT 1 - vagyis érkezik egy magas bit aminek ugye mindig a BEJOVO_TEMP 0. bitjére kéne kerülnie (hiszen jobbra forgatás után igy lenne helyes), - szoval STATUS, C 1- re áll ugye. Majd forgatjuk BEJOVO_TEMP - et. DE a BEJOVO_TEMP csak nullákból fog állni nem?
Hahó! Olvasgatom a DS1620 adatlapját, minden regiszterre azt írja, hogy 9 bites. Az nem baj, hogy Te ebben a RECEIVE rutinban 8 bites adatot olvasol? Gondolom, a SEND-ben is 9 bitesként kellene küldeni az adatot, vagy nem?
Nem mert az elküldött parancsszavak csak 8 bitesek, a CONFIG regiszter is csak 8 bites. Az olvasás pedig úgy van megoldva hogy először kiolvassa az LSB - t (8 bit)
majd kiolvassa az FSB - t (8 bit). igaz ennek csak az első bit- je az érdekes a többi mindig nulla.Igaz meg lehetett volna irni 9 ciklusosra is csak akkor figyelni kéne hogy a 8. bit után mentse le egy regiszterbe, majd a kilencediket egy másikba. Az eredmény ugyanaz. Idézet: „Melyik kódot nézted mert volt már fent pár verzió.” Fogalmam sincs, elkezdtem visszafele menni lapozgatva a PIC mierteket es ahol lattam csatolmanyt Toled azt nyitottam meg - de lehet egy regebbit sikerult, es nem vettem eszre azota mar kuldtel ujabb kodot. Na, most megtalaltam az ujabb verziot - ugy latszik mar ket korty kave is jot tesz a szememnek 
Pontosítom magam: a STATUS regiszter írásakor/olvasásakor 8 bitet ír. Azt sehol nem találom, hogy a parancsok milyen hosszúak.
Igen, már látom a szövegben, hogy a 2x8 bit is elfogadott módszer a 9 bites adatok továbbítására. A RST-t minden kommunikáció előtt/után billented?
Idézet: „Ha a DAT 1 - vagyis érkezik egy magas bit aminek ugye mindig a BEJOVO_TEMP 0. bitjére kéne kerülnie (hiszen jobbra forgatás után igy lenne helyes), - szoval STATUS, C 1- re áll ugye. Majd forgatjuk BEJOVO_TEMP - et. DE a BEJOVO_TEMP csak nullákból fog állni nem?” Nem. Veszed az elso bitet, gyakorlatilag bele forgatod a BEJOVO_TEMP legfelso bitjebe (BEJOVO_TEMP,7). Mivel ezt a muveletet 8x vegzed el, a legvegen a legelsonek bejovo bit lecsuszik a BEJOVO_TEMP,0 poziciora. Magyaran a BEJOVO_TEMP nyilvan csak akkor lehet csupa nulla, ha a bejovo adatfolyam is csupa nullat mutatott. Amugy egy kis 'trukk' : Amikor a DAT portjat magas impednanciara allitod, akkor "TRISA,0" -t irsz. Ha a fejlesztes kozben megvaltoztatod a portot, akkor konyebb lenne szerintem szinkronizalni a kodot, ha oda is egyszeruen "DAT" -ot irnal - hiszen a bankolas miatt ugy is a PORTA a TRISA-ra fog mutatni... A masik, hogy az ISR vektoron egy GOTO-t latok ugyanarra a pontra ahova a reset vektor is ugrik. Ez igy nem jo, ha nem akarod az interruptokat kezelni, akkor egy RETFIE-t kell oda tenni (marmint ha biztos-ami-zicher elven le akarod kezelni az interruptokat. Amit meg csinalhatsz debughoz: A BEJOVO_TEMP-et egy-az-egyben kirakod egy PORT-ra amin 8 db LED-et hajtasz meg, igy lesz egy binaris keped arrol mi jott be - ott megakasztod a PIC-et, es latni fogod mit valaszolt, az jonak tunik-e avagy csupa nulla stb...
igen.
Bár igy van a programban: BSC RST write read BCF RST gondolom igy jó
Igen, így jónak kellene lennie az én logikám alapján is, meg amit az adatlap ír, talán az alapján is.
Nemrég, amikor a DS1821-gyel szenvedtem, ott is belefutottam abba, hogy nem elég a kommunikáció elején egy "reset-present"-tel iniciálni, hanem minden művelet előtt kell. Ha jól olvasom az adatlapot, akkor itt is így kell lennie, azaz RTS fel, parancs ki, adat ki vagy be (ha van), RST le; és a következő parancsnál ugyanez.
Az a mérgesítő hogy már csak a SEND meg a RECEIVE van benne szinte meg az inicializáló. Csak annyit kéne csinálnia hogy belerakok 8 bitet a regiszterébe és megvizsgálom hogy mondjuk a 0. milyen. De nem az amit beleírok. A rutinoknak menniük kell már több helyen megnéztem. mégis mintha a BEJOVO_TEMP fölvenne értékeket de nem jókat. és mindig ugyanazokat függetlenül mit küldök neki. PL a BEJOVO_TEMP,0 mindig 1 lessz, a BEJOVO_TEMP,7 pedig mindig 0, bármit írok bele.
Ez a vizsgáló rutinom:
De a BEJOVO_TEMP-et valtoztatod a RECEIVE-ben...
A RECEIVE elméletileg beleteszi a BEJOVO_TEMP - be a DS1620 STATUS regiszter bitjeinek értékeit. persze hogy változik.(8 szor). RRF BEJOVO_TEMP,F
Mi a hiba???
Nekem amíg a CRT monitorom volt, addig is így teszteltem.
Akkor viszont nem ertem ezt a kerdest:
Idézet: „Az a mérgesítő hogy már csak a SEND meg a RECEIVE van benne szinte meg az inicializáló. Csak annyit kéne csinálnia hogy belerakok 8 bitet a regiszterébe és megvizsgálom hogy mondjuk a 0. milyen. De nem az amit beleírok. A rutinoknak menniük kell már több helyen megnéztem. mégis mintha a BEJOVO_TEMP fölvenne értékeket de nem jókat. és mindig ugyanazokat függetlenül mit küldök neki. PL a BEJOVO_TEMP,0 mindig 1 lessz, a BEJOVO_TEMP,7 pedig mindig 0, bármit írok bele.” Szoval a RECEIVE-et megvaltoztatod, hogy mondjuk csupa 1-est irjpon bele, es megsem lesz benne csupa 1?
Te, az a ket ASM amit beinkludalsz mit csinal? Azt ha meg tudnad mutatni, mert mindig hivogatod a RECEIVE-ben a WAIT makrot es lehet az tesz be neki?
Aza agond akár 1 - et akár 0 - át küldök mindig egy lessz:
A CALL SEND elküldi a KIMENO tartalmát
késleltetés lenne. Ez előre meg volt írva
Nade: az RST-t a kommunikáció előtt fel kell emelni, és a legvégén kell leengedni. Ha jól látom, Nálad a 0xAC command byte után le lesz húzva, ami adatlap szerint megszakítja a kommunikációt. Szerintem így kellene:
RST high SEND 0xA2 RECEIVE RST low
Nos én is így csinálom csak előtte a paranscot berakom a KIMENO - be mert a SEND rutin ebbőla regiszterből küld adatokat. De a CALL SEND előtt én is felhúzom:
BSF RST és csak a bit vizsgálat előtt eresztem BCF RST
Itt a kommunikáció már jónak tűnik, ha a SEND és RECEIVE jól dolgozik. (Viszont azt nem tudom, nem állítódik-e el esetleg a kiválasztott bank valamelyik hívott rutinnál.) A másik, ami érdekes lehet, hogy a CONFIG/STATUS regiszter az adatlap szerint tartalmaz két fix bitet, lehet, hogy azokat meg kellene tartani olyan állapotban, ahogy az adatlap írja.
|
Bejelentkezés
Hirdetés |
