Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
LED-ekkel meg kéne vizsgálnod, azaz körül kéne határolnod azt a területet, ahol elakad a program. Egy ilyen jellegű hibát nem hiszem, hogy külső szemlélő meg tud találni, még ötlet szinten sem(bár van itt egy két varázsló, ki tudja! :heureka: )
nem tudom mit értesz az alatt hogy elakad, meg hogy ezt hogy lehetne LEDekkel! De ha azt érted alatta hogy kifagy, akkor tuti nem fagy ki fut tovább minden! A probléma hogy reset után az első int okoz megszakítást de a többi már nem!
De most rájöttem valamire! működik, csak nem elég gyorsan! A megszakítások között 5-10 másodpercnek kell eltelnie, hogy mind1ik megszakítást okozzon. De hát így meg soros portot 19.2kbps en kicsit nehéz
5-10 másodpercenként tudsz csak egy megszakítást fogadni??? Valahová nem kóborol el a programod az interrupt-rutinból, vagy nem hülyül be egy késleltetés pl. egy véletlenül beírt regiszter miatt?
Közben eszembe jutott valami, de az előzőt már nem tudom módosítani.
Én nem késleltetéssel csinálnám, hanem időzítéssel (mondjuk eleve nem szeretem a késleltetéseket). Alaphelyzetben egy Timer elő van készítve, hogy fele annyi időnként okozzon megszakítást, mint amennyi egy bitidő, de a Timer NEM fut. Amikor megjött az INT megszakítás, akkor elindítani a Timert. A Timer megszakításban olvasni a lábat, növelni egy számlálót, illetve átállítani a Timer periódusidejét a bitidővel megegyezőre. Így minden Timer megszakításkor beolvasod az aktuális bitet. Először a startbitet, majd sorban a többit, és a végén a stopbitet. Hogy melyik bitnél tartasz éppen, azt a számlálóból tudod. Ha ez a számláló elért 10-re, akkor megvolt a stop bit is, újra félperiódusra elő kell készíteni a Timert, törölni a számlálót és engedélyezni az INT megszakítást, illetve jelezni a főprogramnak, hogy megjött az adat.
a timeres dologot hanyagolnám a járható út a késleltetős, hogy miért azt most hagy ne...
Viszont még 1 dolog: konkrétan egy siemens c35i t kötöttem a pic re az okoz bármi gondot hogy a pic 5V a telo 3V ?
Okozhat, de nem biztos hogy okoz. Ha a pic a 3V-os jelet tudja venni 1-nek, akkor jó. A telefon bemenete valószínűleg tolerálja az 5V-ot.
a telefon bemenet az most nem lényeg az tökéletesen működik, az le van korlátozva 3V ra egy ellenállással meg egy Zennerel mert ha 5 voltot kap akkor nincs térerő, de most nem is ez a lényeg!
köszönöm a segítséget de rá leltem higy nem pices probléma van a telo okozza a gondot de még nem jöttem rá hogyan, mert ha lehúzom a telót és én magam húzogatom földre csak egy darab kábellal akkor a megy! szóval passz
Akkor gyanús, hogy nem elég a 3V a pic bemeneti lábán. Mondjuk nem csoda, az RX láb Schmitt-trigger bemeneti pufferrel rendelkezik, 5V tápnál akár 4V-ra is szükség lehet, hogy logikai 1-nek vegye. Ha lehet, vedd lejjebb a pic tápját olyan 3-3,5V környékére, vagy valami más illesztést ki kell találni.
Nekem a siemens-el simán mennek a soros portok...
bladika,
Ilyen egy soros beemelesekbol nem sokat tudunk kihamozni, honnan derul ki ebbol, hogy hogyan lepsz ki az ISR-bol? Honnan deul ki milyen configokat hasznalsz? Honnan derul ki hogy oldottad meg a context savinget? Honnan deul ki hogy jo bankot valaszottal-e ki az INTCON-odnak? Es amugy milyen PIC ez?
Teljesen igazad van, kivéve abban, hogy az INTCON minden bankban elérhető. De a lényegen ez nem változtat, kevés az input!
Hat igen, OP nem kozli a PIC tipusat, automatan mar elo sem veszem az adatlapot (hisz melyiket is?!) es akkor mar automatan at sem gondolom, hogy az INTCON egy ilyen.
Amugy nem tudom mit sporolnak meg azzal vagy mit ernek el azzal, hogy a projectet eltitkoljak es varjak a segitseget? En olvasgatom a piclistet meg a Microchip forumot is rendszeresen, erdekes modon nem szokas titkolozni. Ha a project maga olyan amit nem lehet kozze tenni akkor irnak pelda alkalmazast ami az adott elvarasoknak megfeleloen kellene hogy mukodjon es ami jol szimulalja a problemat igy a tobbiek ra tudnak nezni, hogy itt meg ott ezt es azt csinald es igy mindenki boldog: A kerdezo a problema megoldasat adoptalni tudja a szuper titkos projectjebe, es a kerdezo is a problemara tud osszpontositani nem talalgatni meg konyorogni hogy "hadd oldjam mar meg legysziii" Na most harapos a hangulatom, add ide a kisujjad es leharapom a kezed
Üdv. mindenkinek
Készitettem 1 lakásfűtésvezérlést 16f628-al, 2x16-os LCD, 4vezérlőgomb+reset, 2db ds1820 hőmérsékletszenzor, van "benne". Megszakitásról megy az óra+a 7 nap, napi 5 hőmérsékletet tud variálni. EEPROM-ban tárolom a hőmérsékleti és idő infókat, ezek reset után (3 üzemmód) módosithatók. Gondom "csak" az, hogy néhány hetente kiakad. kb 2x a megszakitás ment tovább, mert reset után tudta, hogy mennyi az idő. Túl nagy tapasztalatom nincs a PIC-ekel, eddig csak 5 holmit készitettem, MPLAB-al teszteltem ott jó volt, a stack miatt módositanom is kellet rajta. Köszi, várom a jótanácsokat 
A szenzorokat milyen hosszú vezetékkel kötötted be a PIC-be?
A másik, hogy a program ismerete nélkül nem fog tudni segíteni senki! Egy jó program nem fagy le, ez tuti! Ezen felül neked is a LED-es hibakeresést, vagy esetleg egy adatgyűjtő csatlakoztatását javaslom, ami figyelné, hogy hol akad el a program. Adatgyűjtőnek jó egy PC, amire RS232-vel viszed a fontos adatokat a kritikus pontok után. (óra, hőmérés stb.) De ismétlem, mi nem tudunk segíteni, ha nem láthatjuk a progit. Esetleg a rajz is jól jöhet(zavarszűrés kérdések stb.). Idézet: „mert reset után tudta, hogy mennyi az idő.” Ezt hogy kell érteni? Az időt rendszeresen eltárolod az EEPROM-ban? Ha igen, nem írod túl sűrűn au EEPROM-ot? Valóban az van, amit watt is írt, hogy valamilyen módszerrel (a legjobb LED-ekkel, netán valami debug infót kiírni az LCD-re) be kellene határolni, hogy hol akad el a program. Az olyan rutinok esélyesek, ahol valamilyen perifériával kommunikálsz, és ennek során valamilyen állapotot kell megvárni. Ha valami elektromos zavar miatt megsérül a kommunikáció, előfordulhat, hogy a várt állapot sosem következik be. Az elektromos zavarvédettség megfelelően van kialakítva?
Udv nemgyuri,
Tegnap mar leharaptam valakinek a fejet Szoval ahhoz hogy segiteni lehessen kellene nemi info. Pl mit ertesz az alatt, hogy "kiakad"? Kapcsrajz+forras nelkul kb meg vagyunk love, es segitseg nyujtas helyett vaktaban puffogtatunk szunyogokra gepagyuval... lehet veletlan eltalaljuk a szunyogot persze Az en lovesem, ami nyilvan nem a problema megoldasa, de tipikusan ilyenek gyors elsimitasahoz jo (hisze epp erre talaltak ki): Kapcsold be a WDT-t, mikor "nem akad ki" akkor ugye hivogasd a CLRWDT utasitast, mikor "kiakad" akkor meg ugy intezd, hogy ne hividjon meg, ezaltal ha a hiba par hetente fellep max resetalodik a pic es megy tovabb - mar feltetelezve, hogy nem mas aramkori problemak vannak)
Köszönöm a fejmosásokat. Kapcs.rajzot most nem tudok adni, mert csak papiron van(ha még megvan), a lábkiosztás a progiban. -fütés.asm- . A "kiakad" alatt azt értettem, hogy a fűtésvezérlés leáll és az LCD-n nincs változás.
A belső szenzor kb 1,5m míg a külső kb 7m-es kábelen van. A táp egy 220/12 ?4W? -7805 pufferelkó+kerámiakondi, a PIC táplábak mellett + kondi. A doboz miatt 3 nyákon drótokkal összekötve. A teszt volt nekem is a legnagyobb gondom, mert nem tudom, hogy hogyan csatlakozhatnék még erre a holmira.
Okés!
Javaslom menjünk sorjában. Első körben ezt az egy vonalas digit távadót gondolom a ludasnak. Kérdéseim: 1. Olvastál valahol arról, hogy mekkora a max. kábelhossz? 2. Nem volt még olyan, hogy véletlenül bekapcsolt a vezérlő, holott nem volt oka? Azt gyanítom, hogy a hosszú kábelen zavarjel jön be, és a hibás adattal nem tud mit kezdeni a programod. Még a progit nem volt időm megnézni, de először ezt a részt kéne lecsekkolni, mert ha egy program hetekig megy, akkor valószínű, hogy inkább ilyen kommunikációs problémák okozzák a hibát. Az a 7 méter biztosan nem ajánlott hossz, de még a 1,5m-is soknak tűnik, de lehet hogy tévedek!(5V-os digitális jeleket nem szokás 20cm-nél hosszabb kábeleken vezetni, ahhoz már illesztővonalak kellenek)
Az első gondok a programodban. Annak ellenére, hogy ha ez lenne a hiba, akkor nem értem, hogyan megy hetekig, viszont hogy nem jó az biztos. Ez pedig a megszakításban a regiszterek eltárolása. Erről már sokszor írtunk másoknak is, nézd meg mi a különbség a helyes és a Te megoldásod között, figyelmen kívül hagyva azt a részt, ami a tiedben nincs is. Kíváncsi vagyok rájössz e, hogy miért kell így csinálni:
Továbbá néztem a hőmérő beolvasási rutint, úgy láttam, hogy nincs hibakezelése. Tévedek?
Kicsit rákerestem, és egy rakás példaprogramot láttam ugyanezzel a rosszul megírt mentéssel. Érdekes, hogy a kilépésnél jól van megírva, míg belépésnél nem.
Igen, ezt én is észrevettem.
Nem tudom, hogy a mentéskor előbb állítódik-e a STATUS, vagy utána. Ha utána, akkor még lehet jó is. Mindenesetre nem szép, és nem a gyári ajánlás szerinti a megoldás, még ha nem is ez a baj.
Csak gyorsan rakukkantottam a kodra, tuzetesebben nem neztem ugyan meg, de van jopar valtozo amik ugyanarra a ram helyre vannak definialva - nem tudom ez igy jo-e vagy sem? Azonkivul a programban vannak kozvetlen ram cimre hivatkozasok is, nem tulsagosan szerencses az igy. Javasolnam, hogy a valtozokat cblock-ba deiniald, ugy konyebb, vagy relokalhato koddal es linker scripttel kellene megcsinalni es "res"-el lefoglalni a helyet nekik.
Azonkivul jobb lenne ha logikai egysegekre lenne bonta, es nem egy nagy gigantikus file lenne a forras. Pl EEPROM rutinok egy EEPROM.INC -ben, vagy ASM-ben es rendesen relokalhatoan linkelni stb. Valahogy a loggolast meg kellene oldani, valoszinuleg rajonnel arra is hol "akad ki" a program. Azt ugyanis meg mindig nem tudjuk, hogy egy signalra var es ezert "beragad" vagy ISR kezelesi gondok vannak stb. Majd ha lesz idom jo lenne tudni hogy lehetne szimulalni egy "felgyorsitott kornyezetben" szoval a par het akar par percre osszezsugorodva talan elohozza a problemat (pl fsosc gyorsitasaval ha igazi kornyezetben teszteled).
Köszi a gyors reagálásokat!
BCF STATUS,IRP -re gondoltál?? Egyenlőre nem látom az igazi hibát, de biztosan van. PCLATH-ot is menteni kell? ez nekem új volt. Mindenesetre kijavitom, de az eredmény csak hetek múlva derülnek ki. A kábelhosszak 10m-ig elvileg nem okoznak gondot, bár az előzetes teszteknél volt olyan tapasztalatom, hogy a ds1820 szenzor egy 20cm-es szalagkábelen volt és hibás olvasások voltak, de csak akkor amikor a jelvezeték melletti szálon -lezáratlanul- volt mindenféle inpulzus.(az egyik PIC láb LCD vezérlése) Hibakezelés valóban nincs a hőmérőbeolvasásnál, de úgy gondoltam, hogy a max. hiba az lehet, hogy 3sec. időre feleslegesen bekapcsolja a fűtést, vagy ki. Tudom trehány vagyok, bocsi.
Ez csak egy példa, ami mindere kiterjedően ment. Nem feltétlenül kell mindent, de ártani nem árt.
Aztán nem a IRP-re gondoltam, hanem a STATUS elmentésére. Azt eleve SWAP-al kell, mert a MOVF állítja a STATUS Z bitet, ami hibás viszatéréshez vezethet. Ez simán okozhat lefagyást. Arra nem válaszoltál, hogy mit írnak a távadó kábelhosszára. Az nem jelent semmit, hogy kipróbáltad, és ment 10méteressel is! Ez szerintem nem erre lett kitalálva. Van aki szerint az USART-ot is össze lehet kötni illesztő nélkül 10méterig, de ez teljesen bizonytalan. Pont elég, ha kéthetente lefagy tőle az egész hálózat.... Nem ragadhat bele a hőfok beolvasásánál a rutinba ha nem jön be bit aminek be kéne jönnie?
Valószinüleg megvan az ok, köszi az ötletet.
A szerkentyü most is megy és így tudtam produkálni a "leállást" azzal, hogy néhányszor kihúztam a hömérséklet szenzorok csatlakozóit. Jó időben történő kihúzásnál "lefagy". Ezt biztosan meg kell oldanom, legkésöbb a következő fűtési szezonig. A kábelhosszt mintha az adatlapból böngészetem ki, legalábbis így emlékszem. A STATUS Z bitre nem gondoltam. Nagyon köszönöm mindenki segítségét, nem gondoltam volna, hogy ennyi segitséget kapok, pláne ilyen gyorsan. Mégegyszer köszi. Idézet: „tudtam produkálni a "leállást" azzal, hogy néhányszor kihúztam a hömérséklet szenzorok csatlakozóit.” Szuper, akkor fülöncsíptük! Idézet: „A kábelhosszt mint ha az adatlapból böngészetem ki, legalábbis így emlékszem.” Értem. Akkor ez egy nagyon jó érzékelő! Ha esetleg megtalálod az erre vonatkozó részt, bemásolhatnád, mert engem is érdekelne akkor az eszköz! Én nem találtam az adatlapban ilyet hirtelen... Idézet: „A STATUS Z bitre nem gondoltam.” Gondoltam! Egyébként ettől függetlenül valószínűleg nem ez okozza a hibát, mint ahogy azt már az elején említettem... Idézet: „Nagyon köszönöm mindenki segítségét,” Öröm volt együtt dolgozni! Kérlek majd jelezd, ha már stabilan műkszik!
Problemak amit a kodben felfedeztem:
BCF STATUS,IRP ;Bank 0,1 BSF STATUS,RP0 ;Bank1 bsf PIE1,TMR1IE IRP indirekt cimzeseknel jatszik szerepet, ebben az esetben nincs jelentosege - ha PR1 eppen jol allt akkor szerencsesen mukodik a rutin... Indul1 -nel a nap nevu valtozo inicializalatlan indulaskor, es annak erteket beteszed DSZ-be... Ha szerencsed van akkor ez 0... Azonkivul ha movlw 0x7 ;1-hétfő.....7-vasárnap movwf nap Amugy ez igy nem lenne egyszerubb?
Ez is azt hiszem egyszerubb lenne igy:
Van benne sok ilyen amin jocskan lehetne egyszerusiteni. Namost lehet erre azt mondod nem egyszerusiteni akarod hanem mukodokepesse tenni, de ha egy kod egyszeru es atlathato akkor a mukodese is konyebben garantalhato velemenyem szerint. A fuggvenyek es kodreszletek ele tegyel megjegyzeskent un. fuggveny fejleceket, es akkor megintcsak jobban lehet latni mi tortenik, mi hol kezdodik, mi az ami ki van tesztelve, mi az ami nem stb... pl ehelyett:
valami ilyesmit tudnek elkepzelni:
|
Bejelentkezés
Hirdetés |
