Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Igy sem jó. Világít a ledem mint az állat.
Idézet: „Aza agond akár 1 - et akár 0 - át küldök mindig egy lessz:” Mi lesz 1? Ami kimegy a vonalon?
Jó lenne az összes vett bitet látni valahogy, ahogy trudnai is utalt rá korábban.
Hú jól belehúztatok, nem győzök olvasni!
Ahogy látom ott vagyunk ahol eddig. Minden jónak tűnik, még sem működik. Szilva említette, hogy van két bit, ami mindig ugyanaz, azokat át se lehet írni! Azokat kéne kiolvasni, hogy egyáltalán lehet e értékelhető eredményt kapni a hőmérőtől! Én is javaslom, hogy az egész bájtot kéne kiolvasni és utána tesztelni a biteket egyenként. delmur82 kérdezted: Idézet: „Hogy a fenébe kerül bele a BEJOVO_TEMP - be az érték?” Vizsgálja az adat vonalat, majd annak állapotától függően beállítja Carry bitet. A következő utasítás az RRL ami ezt a bitet belépteti a BEJOVO_TEMP-be. Ez így jó! Az a vicc, hogy minden jónak tűnik, még sem megy. Én már a hőmérőre is gyanakszom!
az előző oldali hosszú kódot ha megnézed a A "DS1620 konfigurálása" részben kiküldök egy parancsot és egy adatot. A parancs a WRITE CONFIG , ami annyit tesz hogy a DS1620 tudni fogja hogy a következő bejövő 8 bit az ő CONFIG regiszterét fogja írni. Az adat amit küldök a b'00000000' . Namost a gond az hogy sajnos nem tudom leellenőrizni hogy a 8 bit beíródott e a CONFIG regiszterbe.(itt természetesen minden esetben a DS1620 CONFIG regiszteréről van szó.) Ugyanis ahhoz hogy én vizsgálni tudjam azt a regisztert ki kell olvasni a tartalmát , beletenni egy a PIC - ben található regiszterbe (ez nálam a BEJOVO_TEMP). Szoval nem tudom eldönteni hogy az adat már el sem megy a CONFIG regbe vagy elmegy de a kiolvasás nem jó. Az én vizsgáló rutinom a BEJOVO_TEMP - et vizsgálja. De ahogy már írtam pl. a 0. bit mindig 1. Pedig én ahogy le is írtam 0 - át küldök.
Üdv!
A szenzor vadi új. Nem először rakok össze PIC - es áramkört úgyhogy a DS1620 is foglalatba van. Forrasztva nem volt. A tápot jól kapja el sem romolhat. De talán érezve valamit kettőt vettem úgyhogy ha hazaérek kipróbálom a másikkal is. Dehát nemtom.
Hulye kerdes, de a scope-on latszik, hogy a PIC tolja ki a parancsot, meghozza helyesen? Mondjuk ehhez tarolos scope vagy logikai analyzator kellene...
Ezt egy pár oldallal korábbi verzióból ollóztam ki:
Az adatlap ezt írja (kiemelés tőlem): For data inputs, the data must be valid during the rising edge of a clock cycle. Data bits are output on the falling edge of the clock and remain valid through the rising edge. Szerintem a fenti kódrészlet ennek nem felel meg. Mielőtt a bitet állítgatod a küldendő adat legalsó bitje szerint, pont magasban van a CLK, és miután beállítottad, utána lesz rajta egy lefutó él. Ahogy én az adatlapban látható idődiagramot nézem, a következőnek kellene történnie a ciklusban: CLK low adat bit beállítása CLK high A CLK high-ba állítását pedig még a RST felemelése előtt illene megtenni a kommunikáció legelején.
Akkor romolhat el esetleg, ha szembe kerül két kimenet. Úgy emlékszem első körben nem volt az adat vonalban védő ellenállás, most van?
Idézet: „A CLK high-ba állítását pedig még a RST felemelése előtt illene megtenni a kommunikáció legelején.” No ez már egy jó meglátás! Még az inicializálás előtt H-ba kéne tenni, és minden rutinba úgy belépni, hogy H!
Sajnos nem tudom, melyik az aktuális verzió, lehet, hogy én régit néztem, mert volt olyan is itt, amiben már a pozitív élnél van kint az adat.
Ellenben én is pont azt néztem, hogy a legelső SEND vagy RECEIVE előtt a CLK vonal alacsonyban van, semmi nem emeli azt fel. Az adatlap szerint pedig az RST felemelése előtt már a CLK-nak magasban kellene lennie. Az első kommunikáció után már magasban marad, de a legelső előtt nem, és lehet, hogy emiatt nem megy el megfelelően az a legelső, írási parancs. Még mindig azt mondom, hogy jó lenne látni a RECEIVE által beolvasott összes bitet, akár azon az 1 LED-en lemorzézva, mert abból nagy valószínűséggel láthatnánk, hogy van-e kommunikáció, és a parancsok szintjén kell csiszitolni még, vagy egyáltalán nem jó a kommunikáció. Idézet: „Az első kommunikáció után már magasban marad, de a legelső előtt nem” Igen, és pont a konfiguráció előtt nem, ami így meg is híusúl!
Nos hazaértem.
Először is kicseréltem a szenzort, ugyanúgy működik. Szenzorhibát kizárhatjuk. Két új szenzor csak nem romlik el egyszerre Beleraktam a configurálás elé a BSF CLK - t. Bár nem nagyon értem mit jelent az hogy magasabban. Valami vagy magas vagy alacsony nem? Hiába raktam 1 - be a SEND - be úgy is 0 - ra kerül a RST meg marad 1 - en. Megnéztem bitenként a visszajövő adatot: 00000001 Ez jön vissza mindig, függetlenül attól hogy az iniciálós részben mit küldök. Ezen azt élrtem ne tévesszen meg senkit hogy az init részben pont ez van jelenleg. Ha minden bitet átállítok akkor is a fönti jel jön vissza. Felrakom a kód azon részét ami eddig kész a fölös dolgokat kivettem (CALL START_ CONVERT és CALL READ_TEMPERATURE.)MAjd ha működik az ellenőrzés mehet a convertálás is addig fölösleges. Ha van ötlet szivesen várom még.
Ez egy régebbi verzió.
A fönti proba2.asm - et nézd. Idézet: „Bár nem nagyon értem mit jelent az hogy magasabban. Valami vagy magas vagy alacsony nem?” De. Ez csak egy szófordulat. Magasan kell lennie, hogy onnan le lehessen vinni. A CLK-nak mindig magasban kell maradnia a kommunikációk végén, ezt le is ellenőrizhetnéd!
Keresztkérdés! Van az RA4-en felhúzó ellenállás?
Persze, hogy nincs, látom a nyákon! Az RST soha nem lesz H! Gyorsan tegyél oda egy 1kohm-ot a Vdd felé!
Uhh, ez szép fogás volt!
Valóban, az RA4 itt open drain, és az adatlapból nekem az derül ki, hogy a Dallasban sincs felhúzó.
Akkor huzzam +5V - ra?
a rajzokon ez miért nincs rajta?
Mert nem az RA4-en volt a RST! Igen, húzd fel 5V-ra.
Nos uraim úgy látom sikerült előrelépnünk. Ez hihetetlen. Mi van ezzel az RA4 - el?
Mimimimi? Miez hogy open drain? és miért pont ez? ha másik lábra teszem akkor ok lett volna? Comparátort kikapcsoltam. Az a TOCKI zavart be? ez nem sima digitális kimenet vagy bemenet? Mármint az RA4
Idézet az adatlapból:
Idézet: „PORTA is an 8-bit wide latch. RA4 is a Schmitt Trigger input and an open drain output. Port RA4 is multiplexed with the T0CKI clock input. RA5(1) is a Schmitt Trigger input only and has no output drivers. All other RA port pins have Schmitt Trigger input levels and full CMOS output drivers” Azaz az RA4 kimenetként open drain (nyitott drain-ű, olyan, mint a nyitott kollektoros a TTL IC-knél, csak ez CMOS technológia és itt FET-ekről beszélünk) kimenet tud lenni, az RA5 pedig egyáltalán nem tud kimenet lenni, csak bemenet. A PORTA többi lába teljes értékű CMOS kimenet vagy bemenet is lehet. Idézet: „ha másik lábra teszem akkor ok lett volna?” Igen, de ezen is jó lesz, csak kell az ellenállás. Kíváncsian várom a további eredményeket!
Szóval ez volt a gond. Az én figyelmetlenségem.Na holnap rámászok erre a témára. Amúgy mindenkinek nagyon köszi a sok segítséget. Most már nagyon szépen működik. Ha ráteszem a kezem már jelzi is hogy melegszik szépen aztán visszahül. Jól működik.Hát ez a szép ebben az egészben nagyon farnkó. Holnap neki is leselkedek az LCD vezérlésnek. Azt a PORTB - re terveztem. Remélem ott már nem ér nagy meglepetés.
Köszönöm szépen a válaszokat, kezdetnek átnézem a BIOS-t aztán ha nem megy, újra építem az égetőket még figyelmesebben.
Hello
Szeretnék csinálni PIC-cel 4 digites LED kijelzős órát, amelynek a számjegyei multiplexelve lennének meghajtva. Nos kb. mennyi ideig világítson egy digit? Előtétellenállást hogy számoljak, mennyi áramot engedhetek rá így a LED-ekre? Hányszor többet, mint normális esetben? Üdv.
PIC-es tapasztalatom még nincs a témában, de TTL áramkörös órával már volt dolgom. A kijelző adatlapjában van, hogy mit bírnak a szegmensek, és azt mennyi ideig. Ez alapján kalkulálj. Másodpercenként, 24-25 villanást már egybefüggő világításnak lát a szem, de ez még bántó. Értelemszerűen minél magasabb a másodpercenkénti felvillanás, annál jobb.
Szerintem célszerű a lehető leglassabb multiplexelést használni, ami még nem zavaró, nem látszik villogásnak. Ez azért jó, mert a digitek közti átkapcsoláskor a "szellemkép" jelentősen csökkenthető. Minél gyorsabb a multiplexelés, annál nyűgösebb a szellemkép.
50Hz felett már folyamatosnak látod a fényt, feltéve, hogy nem mozgatod az órát, de mondjuk lehet a biztonság kedvéért 100Hz környékére venni a kijelzőfrissítés ütemét. Ez 4 digitnél 400Hz-es digitléptető ütemet jelent. Aztán lehet kísérletezni, ha kevésnek bizonyulna a gyakorlatban. A LED-ek vagy kijelzők adatlakpjában vannak határértékek impulzusüzemre meg abszolút értékre is, én ilyen 4-es multiplexben maximum a LED folyamatos üzemi áramának duplájával kalkulálnék.
Próbaképpen megküldtem egy 8 digitből álló kijelzőt 8kHz-es léptetéssel (tehát egy kijelző 1kHz-et kapott), de nem volt szellemkép. Szerintem ha szellemkép jelenik meg valakinél, ott az van, hogy nem kapcsolja ki a digiteket, mielőtt a szegmensekre kiküldi az új kombinációt.
|
Bejelentkezés
Hirdetés |
