Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Idézet: „Szerintem össze lett keverve a két AdresX.” Igen, valószínű, ezért is írtam le még egyszer, világosan (szerintem), hogy hogyan kell működnie. Ahogy látom, lassan ki fog alakulni ez a dolog.
Értem már, köszi! Erre nem is gondoltam volna! Normál esetben akkor kapcsol be a fűtés, ha hideg van. Itt viszont nem a fűtés a szempont , hanem a vízhőfok! Szép az élet!
Bizony, az AdresL a BANK1-ben van, ez szép találat volt!
 Viszont ez a sok bank és lapváltás azt eredményezi, hogy több Flashmemó fog erre fordítódni, mint a programra(minden váltás két programsor!)! Tehát ha nem akarunk pazarolni, akkor figyelni kell és csak akkor kell váltani, ha szükséges, és akkor sem biztos, hogy mindkét lap ill, bankbeállító bitet váltani kell). Ez viszont baromi macerás, de elkerülhetetlen. Ezért hagytam fel a 16F-ekkel! 16F felett az élet könnyebb! 
Helló szilva.
Köszi mindjárt kipróbálom. Az biztos, hogy amikor jobbra igazítotttam, és a ADRESH helyett ADRESL-t akartam beolvastatni vele, akkor is az ADRESH értéke jelent meg binL-ben. (remélem jól írtam) Köszönöm, próbálom.
Igen, ez tuti, hogy a bankváltás miatt van.
Amikor a fordító odaér ahhoz, hogy ADRESH, akkor ugyan azt a parancskódot olvassa ki, mint amikor az ADRESL-hez ér, azaz 01Eh-t(mindkét címke értéke ennyi). Ezért kell kiválasztani a memória bankot előbb. Ez olyan, mint négy könyv, amin azonosak az oldalszámozások. Nem mindegy melyik könyv 30. oldalán keresed az infót!
Helló szilva.
Egy nagyon buta kérdés? A saját változóm, mint pl. binL vagy a binH hogy melyik bankban van azt honnan tudom? Elől, ahol definialtam? cblock 0x20 tehát az a '0' BAnk? Köszi. ui. Fiúk, nekem aranyat értek, mert hiába próbálom magamtól mindent, nincsen akit kérdezzek nincsen könyvem ,csak a net, és TI. Köszönöm.
Helló FIúk.
MŰKÖDIK. Most jön majd az összehasonlítás a mért értéket, egy másikkal. De nincs compare utasítás. Úgy hogy most indul a keresés a neten valamit róla. Köszönöm.
Nem buta kérdés. Igen, abból derül ki, ahogy definiáltad őket. A 0x20 a 0. bank eleje.
Nézd meg a 16F887 doksijában a Figure 2.6-ot a pdf 27. oldalán, abból szerintem minden ki kell, hogy derüljön! Az is, hogy bankváltás nélkül miért kaptál ADRESL helyett ADRESH-t: egymás mellett vannak, azaz a bankon belüli címük ugyanaz.
A komparálás minden esetben tulajdonképpen kivonás, és az eredmény vizsgálata (kisebb, nagyobb vagy egyenlő-e nullával). Vannak processzorok, ahol ezt egy képzeletbeli kivonással is meg lehet állapítani (ezek a compare utasítások), PIC16-on a valóságban is el kell végezni a kivonást.
Két byte összehasonlításánál érdemes előbb papíron leírkálni, hogy melyik byte összehasonlítási eredményétől függően mi a végeredmény.
Helló szilva.
Igen, meg van nekem ez az oldal, már korábban kinyomtattam, csak nem tudtam, hogy mire használjam. Akkor most indul a komparálás. Mégegyszer köszönöm NEKTEK. ui. Lehet, hogy 16F felett könnyebb az élet, de 5-dik X felett már nehezedik.
Szia Potyo!
Elnézést kérek, hogy nem tudtam előbb reagálni, de sajnos közbejött egy két dolog. Mellékelem a kapcsolási rajzot, programkódot stb. Az RF modul és az eeprom nincs rajt a nyákon. Sajnos a problémám még mindig ugyan az. Miért csak akkor müxik a pic program ha mondjuk az RB7 lábat gnd-re kötöm? A videón (bocs a rossz minőségért) látható hogy az ICD2 felprogramozva a resetet kiadva müxik rendesen de csak addig míg az RB7 RB6 is rá van csatlakoztatva. Külső tápegységről (3x1.5v elem) működtetve (Vdd=3.02v Imax= 10mA) a mellékelt led programmal a picben nem villog a led de ha az RB7 összekötöm a gnd vel akkor elkezd villogni a led. Szerintem a rezonátor rosszalkodik, de csak 20MHz van itthon az meg nem lesz jó 3V Vdd-ről. Mihamarabb be kell szereznem egy scopot . Ha van javaslatotok ötletetek annak nagyon örülnék.
Kiegészítve szilva írását a "comparálásról", figyelj, hogy a kivonásnál a Carry 0, ha alulcsordulás volt és 1, ha nem(tehát akkor is, ha a két érték egyenlő volt, azaz kivonás eredménye 0)
A Carry(C) vizsgálata a következő: SUBWF érték,W ; eredmény W-be! nem rontja el az értéket) BTFSS STATUS,C ...ez a sor jön, ha alulcsordult ..ez ha nem.. Az nézd meg, hogy a kivonásnál mi vonódik ki miből, mert az nem mindegy a kiértékelésnél!
Rezonátorra én nem gondolnék, az szerintem vagy megy vagy nem. Lehet, hogy mond majd valaki okosabbat, de számomra ez a két konfig sor kérdéses:
#FUSES LPT1OSC //Timer1 configured for low-power operation #FUSES MCLR //Master Clear pin enabled Nem látok a T1OSI-T1OSO lábakon külső oszcillátort, sőt, ha jól látom, egész más funkciókra használnád ezeket a lábakat. Akkor nem értem, miért kell a LPT1OSC a konfigba. A másik, hogy az MCLR engedélyezett, ezért az ICD2-ről lehúzva a rajz alapján a levegőben lóg, ki tudja, milyen szintnek látja épp a proc. Én legelőször ezt vizsgálnám meg, tennék be egy felhúzó ellenállást a Vdd felé.
Helló Watt.
Köszönöm a kiegészítést. Lassan de felfogom. És azt hogy tudom meg, hogy egy szám egy adott érték, vagy felett van. Ez az a alulcsordulás? Köszönettel
Helló watt.
Nem pontosan fogalmaztam. ....a szám, egy adott érték alatt, vagy felett van.... Köszönettel.
Igen Silva, ahogy nezegettuk kozosen a rajzot felmerult, hogy az MCLR lehet nem is lebeg, hanem egy 100k-val van felhuzva a Vdd-re? Ez nem egeszen egyertelmu a rajzon. Ha 100k, akkor en lecserelnem 10k-ra vagy 20k-ra max, ha pedig log, akkor bele kell tenni a felhuzast vagy lekapcsolni konfigban.
A masik ami nekem nem tetszik, hogy a power up timer ki van kapcsolva, ami lehet nem szerencses, mert ki tudja hogyan eled fel a rezonator es ennek milyen kovetkezmenyei vannak. RF modulnal sem a foldet kapcsolgatnam, de ez mar egy masik kerdes. Udv, Tamas
Egy kivonással (vagy összeadással) csak azt tudod meg, hogy felette van-e vagy sem. Az, hogy nincs felette, az jelentheti azt is, hogy egyenlő vele. Tehát ha azt akarod eldönteni, hogy felette vagy alatta van, ahhoz két ellenőrzést kell csinálni.
MÁr kérdeztem, de nem találtam sehol választ, hogy miért eredményez egy szimpla printf függvény C30-as compilerrel iszonyat mennyiségű kódot?
A függvény semmit nem csinál, csak elküldi egyenként a karaktereket. Heap size=200 bájt.
A printf annyi minden formázást, változótípust ismer, hogy iszonyat. Gondolom, ha csak egyszer is használod, akkor az egész kód, ami ezeket megvalósítja, az belekerül a végtermékbe, ha kell, ha nem.
Szerintem csupán ennyi az oka. Valószínűleg érdemes saját kis formázó rutinokat írni kizárólag azokra az esetekre, amikre épp az adott progiban szükség van, így sokkal tömörebb lesz az eredmény.
Köszönöm, sanda a gyanú, hogy ez a helyzet áll fent.
Meg kéne nézni, hogy a printf függvény mit is csinál valójában. Tudom, hogy nem túl barátságos megközelítés, de a listing fájlba kellene belenézni.
Én ezért nem szeretem a gyári függvényeket, sosem tudom, hogy mit csinálnak, és mennyi ideig tartanak. C-ben is úgy írok programot, mintha asm-ben írnám, és azt is meg szoktam nézni, hogy pl. egy elágazást hogyan fordít, és ha nem tetszik, akkor addig variálom, amíg nem olyan kódot eredményez, amit én szeretnék.
Nekem is pontosan ez a "mániám", de most hogy így mondod, látom nem vagyok egyedül vele. Gondoltam majd hülyének néznek, hogy mindenre külön függvényt írok, ami már úgyis megvan, de szerintem is használhatatlan egyik-másik....
Tudod, hogy egy bájton a legkisebb szám 0, ha ebből kivonsz egy n számot (0 - n, ahol n>0), akkor a bájt nem mínusz lesz, hanem elkezd vissza számolni 255-től. Tehát 0-1 = 255 és így tovább. Tehát, ha átfordul a 0-án a bájt értéke, akkor azt alulcsordulásnak hívjuk(kivonásnál). Ha pedig 255-ön fordul át, akkor túlcsordulásról(összeadásnál). Ezt az eseményt jelzi a C(Carry), ami a STATUS(állapot) regiszter egyik bitje. Ezt kell vizsgálni a fentebb leírt módon, és elágaztatni a programot a C függvényében.
Ha azt is akarod tudni, hogy 0-e az eredmény, akkor a Z(Zero) bitet is meg kell vizsgálni. Nézd meg a STATUS regiszterben milyen jelzőbitek vannak még(nem sok!). Idézet: „C-ben is úgy írok programot, mintha asm-ben írnám” Na ja! Már én is azt hittem, hogy csak én csinálom így. Tiszta gáz, hogy nem használok csak matekos függvényeket. Tudtam, hogy ez PIC esetében teljesen normális, csak nem sejtettem!
A gáz az, hogy elvesztettem az ps2-usb átalakítóm forráskódját, mert elfelejtettem lementeni formatáláskor
 Csak a hex van meg a kontrollerből visszaolvasva...
Potyo,
Kb egy eve vagy lehet tobb is mar elkezdtem egy GNU projectet egy PIC disassemblerrel kapcsolatban. Valamennyire mukodik 14 bites PIC-ekre, talan segit neked: http://unpic.sourceforge.net/ Perl-ben kezdtem el fejleszteni - mondjuk akar at is lehetne alakitani C-re, de igy legalabb minden platformon lehet futtatni ahol van Perl. Egy Win EXE forditast is csinaltam ra, de az ha jol emlekszem nem a legeslegutolso valtozat. (Lehet folyatni kellene, csak idom eleg kevesnek bizonyul) Udv, Tamas
Hello pichez nincs valami grafikus kod szerkesztö vagy hogy lehet ezt könyen megtanulni?
|
Bejelentkezés
Hirdetés |
