Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Földre kötöttem, Icserny mondta.
Én úgy látom, azt vezérelni kell. Próbáld meg, hogy kitolsz egy adatot, majd kézzel leviszed testre, majd vissza. Meg kell jelenjen az adat.
Ha folyamatosan testen van, szerintem nem történhet semmit, mert a latch nagy valószínűséggel lefutó élre érzékeny. Persze lehet, hogy tévedek, de ha nem lenne rá szükség, minek tették volna rá!?
Itt is földön van:
Bővebben: Link Meg itt is: Bővebben: Link De amúgy próbáltam azt is hogy kézzel levittem egy kicsit a földre. Semmi nem változott sajnos. :no:
Akkor tényleg nem tudom minek tették rá azt a lábat...
Nehéz egyébként elhinni, hogy rossz az IC, de nem zárható ki.
Az adatlap írja (6.1 alfejezet): "Note that LDAC is active-low. If desired, this input can be tied low to reduce the required connections from 4 to 3. Write commands will be latched directly into the output latch when a valid 16 clock transmission has been received and CS has been raised."
Az LDAC bemenet előnyét pedig a 6.1 ábrán mutatja: két vagy több DAC frissítését lehet vele szinkronizálni (kettős bufferelés). Attila, a PICkit2 Logikai analizátor módjában ellenőrizted már a jeleket? CS akkor mehet vissza magas szintre, ha pontosan 16 db. órajel érkezett! Egy aktuális kapcsolási rajzot azért mutathatnál!
Szia!
- Milyen szint mérhető a VrefA és VrefB lábakon? - Milyen szint mérhető a SHDN lábon? - Nincsenek nagyon megterhelve a kimenetei? A PICKit2 Logikai analizátorával vedd fel a jelalakokat... A feltöltött kódommal hibamentesen kezelek MCP4922 -t 18F2523-nal 40MHz órajellel. LDAC nálam is a földre van kötve...
Sziasztok!
Kis segítséget szeretnék kérni. Eddig főként PIC18F sorozattal dolgoztam, mostanában térek át a 16 bitesekre, nevezetesen jelenleg dcPIC30F4011 és PIC24HJ128GP504 MCU-kal dolgozom, ill. tanulom a lelkivilágukat. A külső kvarcoknál ill. az oszcillátor konfigurációknál akadtam meg kissé. A másodlagos kvarcot érteni vélem, mert ugye oda akkor rakok 32,768 kHz-es kristályt, ha óra és dátum funkciót akarok használni. No de mi határozza meg, hogy az elsődleges oszcillátornál a belső 7,37 MHz-es FRC oszcit használom, vagy külső kristályt rakok XT, vagy HS konfigurációban? Nem igazán tudom hova tenni a dolgot. Talán az dönti el, hogy az osztókkal előállítható frekvenciát mekkorának akarom? Vagy valami más elv a kulcs? Meköszönném, ha valaki megvilágosítana... :nemtudom: (egyébként C30 compilerrel dolgozom) Idézet: Természetesen te döntöd el, hogy mit akarsz használni! Célszerű bekapcsoláskor a belső FRC óráról indulni, s a 7,37 MHz-es alapfrekvencián ketyegve beállítani a PLL osztókat (figyelembe véve az előírt határokat), s végül átváltani az üzemmódot.„mi határozza meg, hogy az elsődleges oszcillátornál a belső 7,37 MHz-es FRC oszcit használom, vagy külső kristályt rakok XT, vagy HS konfigurációban?” Ha jól emlékszem, 8 MHz-es kristályig XT, azon felül HS módot kell választani. A PIC24HJ128GP504 mikrovezérlő esetében a PIC24H Family Reference Manual 39. fejezetét kell nézni. A PIC-kik projekt mintapéldáinál a LED villogtatása II. bemutatja, hogy a belső oszcillátort hogy lehet beállítani ~80 MHz-re. A külső oszcillátorok használatához az include/pic24_clockfreq.h és a common/pic24_clockfreq.c állományokat kell áttanulmányozni. Az utóbbi legvégén található például az az eljárás, ami 16 MHz-es kvarchoz állít be 80 MHz-es CPU frekvenciát. A PIC-kwik projekt sok automatizmust tartalmaz, csak a CLOCK_CONFIG szimbólumot kell beállítani a pic24_libconfig.h megfelelő sorának aktiválásával (ha nincs definiálva, akkor FRCPLL_FCY40MHz az alapértelmezett), s a többit a makrók elvégzik a főprogram elején kiadott configClock() vagy configBasic(HELLO_MSG) függvényhívás hatására. Természetesen az utóbbi is a configClock()-ot hívja meg belül...
Sziasztok!
Először is had mondjak köszönetet mindenkinek! -hogy türelmes volt hozzám, és segített. Sikerült megoldani az ADC konvertálást. Ideiglenes: jogos, amit írtál, hogy túlléptem az int16 -os korlátot, de én mint kezdő PIC-es józan paraszti ésszel belegondolva azt hittem, elég az int16, hiszen az osztás szorzás végértéke bőven belefér a határba. A fene gondolta, hogy így dolgozik: int16 X; Ezt szeretném kiszámolni: X = (4090 * 100) % 4095; Első lépés: X = 409000; (4090 * 100) Második lépés: X = 3595; (409000 % 4095) Logikusan úgy gondoltam, hogy nem rakja bele a részeredményt a végeredmény változójába, hanem valamelyik felhasználói memória területen tárolja ideiglenesen; mint a "magas szintű nyelvek"(Delphi,stb.). A jó kód:
Ez a CCS büntetése? -ahogy watt írta, vagy minden PIC/fordító így dolgozik? Az MPLAB-ot feltettem, megtalálta magától a CCS-t, de nem kezeli a CCS programomat, pedig már ezt is átnéztem itt. Nagyon sok eltérés van illetve nehezebb az MPLAB a CCS-nél? -mert ha nem veszélyes a különbség, inkább áttérek, ott is lehet C-ben írni, de láttam egy két igen furcsa regisztert és hasonlót. Mert ahogy itt és máshol is olvasgatom, sokkal jobb, csak félek a sok TMR0 regisztertől....  Köszönöm! Sanya
Ez nem a CCS hülyesége, gyakorlatilag a C nyelv ilyen. Egy kifejezés kiértékelésekor az operandusok közül a "nagyobb hosszúságú"-ra konvertálja a "rövidebbeket" és az eredményt a "hosszabbik" hosszában számolja ki. Ezért ha pl. i egy 16 bites int, akkor az (i * 4095) 16 biten fog kiszámolódni, ugyanis a 4095 konstans is belefér 16 bitbe. Ha viszont (i * 4095L) -t írsz, vagy ( ((long) i) * 4095 )-öt, akkor már a részeredményt 32 bites long-ban kellene kiértékelnie, és nem veszne el adat.
Persze a különböző C fordítók között lehet különbség az int, long és egyéb típusok szóhosszúsága között, tehát azt, hogy az adott fordítón konkrétan mi történik csak akkor tudja megmondani az ember, ha utánanéz a fordító által kezelt típusoknak. Az egyik példában a sok zárójelet sem véletlenül tettem ki: így biztos a kiértékelés sorrendje, és az, hogy a casting mire vonatkozik. De ezek mind C-s kérdések, és nem sok közük van a mikrovezérlőkhöz, a PIC-hez.
Szia!
A CCS oldalán ott van a hiányzó láncszem... A MpLab plugin. Töltöd le, installáld, az MpLab segítségével hozz létre egy projectet a feladathoz, amiben a CCS nyelvi környezetet válsztod ki, és a programodat add hozzá a projecthez. Ellenőrizd le a fordító elérési útjainak beállítását. Ezután az MpLab környezetben tudod fordítani a CCS programot. Válaszd ki a MPLAB Simulator -t debuggernek. Fordítsd újra a programot. Ezek után lépésenként is tudod futtatni a programodat ... A magasabb szintű nyelvek sem használnak általában az operandusoknál nagyobb szóhosszúságot a számításhoz. Kivétel persze van (basic, ..), azok mindent float / real -ban számítanak és a számolás végén konvertálják az eredményt a kimeneti változó típusára. Ebben az esetben rengeteg kerekítési hiba keletkezhet a számítás során...
Sziasztok!
Köszönöm a válaszokat! szilva: értem mostmár a számítási "problémámat", és elnézést, hogy itt kérdeztem erről, ez valóban C tropic. Hp41C: fent van a plugin, minden úgy van, ahogy írtad, (de nem fordul, a void main sornál error) kivéve talán "Ellenőrizd le a fordító elérési útjainak beállítását." -nem csak a ccs.exe kell neki?-mert a weboldalukon csak azt mutatja, de majd szétnézek ezügyben. Számítás Delpiben: procedure ... var egesz, tized, szazad: byte;(0..255) Tmp: word; (0..65535) és gond nélkül leszámolja, ezért nem értettem a dolgot, de ez már valóban nem ide tartozik. (Jövőhéten I2C és SPI vel jövök vissza  )Köszönöm Mindenkinek, sok mindent megtanultam! Sziasztok! Sanya
Szia! A CCS büntetését úgy is értettem, hogy ha nem olyan fejlesztő környezetet választ valaki, amit sokan használnak, pl. Hi-Tech, mcc18 és a többi microchip által támogatott fordító, akkor úgy járhat, hogy kevesebben tudnak segíteni. Én is ajánlottam a szimulációt, egyből kiderült volna hol a turpisság! De konkrét segítséget nem tudtam adni, mert soha nem használtam a CCS és nagy valószínűséggel nem is fogom.
A C változó típusaíról még annyit, hogy ha valaki C-vel kezd PIC-et tanulni, így jár. Ha ASM-on nevelkedtél volna, belelátnál a C vénájába és tudnád, hogy a dolgok nem úgy működnek, hogy x=gyök(25^3/2,345001522) Ez akkora kódot is eredményezhet, hogy egy kisebb PIC tele lesz 4-5 ilyen számítással...
Köszi István, nagyon sokat segítettél!
Egyszerűen abban voltam bizonytalan, hogy mi a meghatározó irányelv ebben a dologban. A PIC-kwik projektet sűrűn "forgatom", nagyon sokat tanultam már eddig is belőle, és még csak kis részén vagyok túl, (hadd dícsérjelek szembe :rolleyes többet ér, mint sok szakkönyv...Dupla feladatot csináltam magamnak, mert nemcsak MCU családot váltottam, hanem nyelvet is, eddig CCS C-ben dolgoztam. Így azután néha (jelenleg még elég sűrűn) csak kapkodom a fejemet...  Még egyszer is köszi a gyors segítséget !
Szia.
Sajnos egyszer már én is jártam így. Valamit elrontottam az elektronikán, azután a PIC csak olvasható lett. Az elsőnek beleírt program futott, fut még most is. Olyan, mintha a törlés működne, de mégsem törlődik a tartalom.
István, még egy kérdés... Olvasgatom a 39. fejezetet és azt olvasom, hogy az FRC esetében nyilván a hőmérséklet és a feszültség befolyásolja a frekvencia értékét, ill. ingadozását. Ezek szerint arra gondoltam, hogy tehát akkor használok FRC-t, ha kisebb órajel-pontosságú feladatokat kell megvalósítani, pl. LED kezelés, LCD kezelés, nyomógomb figyelés, stb. Ha viszont mondjuk egy nagy felbontású AD konverzió a feladat, akkor érdemesebb XT, vagy HS módban külső kristályt alkalmazni, igaz? Hiszen mindkét módon elő lehet állítani pl. 40MHz órajelet, de az már nem mindegy, hogy az mennyire lesz stabil. Jó gondolkodom az alkalmazást illetően, vagy eltévedtem?
Idézet: „(de nem fordul, a void main sornál error)” Mi a hibauzenet? Es hol van a kerdeses sor?
A/D-hez nem az orajelnek kell pontosnak lennie, hanem a feszultseg referencianak, ill a vonali zajoknak kellene minel kisebbnek lenniuk.
Pontos ora mashoz kellhet, pl asynchron soros kommunikaciohoz (ld. meg USB, RS232), ha ebreszto orat szeretnel megvalositani, ha frekvencia merot, VFO-t stb tehat mind ahol a valos eletben is kritikus lehet az idozites. Idézet: Akkor ez PIC16Cxx tipusu volt, vagy esetleg AVR. Meg nem lattam olya "flash" picet, amit nem lehet torulni. „azután a PIC csak olvasható lett”
Ok, köszi, természetesen igazad van az A/D-vel kapcsolatban, igazából azt akartam kifejezni, hogy ha pontosan mindig ugyanakkor akarok mintát venni valami miatt, akkor érdekes a pontosság...
De akkor végül is jól látom az FRC, ill. a külső kristály választásának lényegét, hogy az a kívánt pontossággal függ össze? Idézet: Igen, a pontossággal. „De akkor végül is jól látom az FRC, ill. a külső kristály választásának lényegét, hogy az a kívánt pontossággal függ össze?”
Igen, egy kristaly oszcillator mindig pontosabb lesz, mint egy RC. De van a belso oszcillatorra nemi tuningolasi lehetoseg, amivel el lehet +-10% iranyba huzni a frekit ha pontatlan.
Szia!
A PC processzora 16 (8068 - 80286), 32 (80386 - Pentuim.. ), 64 bites. Külön előlködni kellene a 8 bites műveletek elvégzéséért. A pic-ed csak 8 bites, így a 16 vagy a 32 bites műveleteket 8 bitesekre vezeti vissza. A programhely korlátozott volta miatt a lehető legkevesebb műveletre (próbálnak) fordítani.... A példád kapcsán letöltöttem és installáltam a plugin -t, működik. A project létrehozásánál be kell állítani a használt pic típusát... Gyanúsan viselkedik, ha eltérő a kontroller típusa az MpLab -ban és a CCS forrásban...
az udata_acs direktívát próbálgatom és a következő érdekességet találtam az alábbi kódban:
Fordítás után a .lst file a /movwf a/ ra 6E??, a /movff/ re c??? - f???, a /movwf a+1/ re 6e?? et fordított. Simulátorral kipróbáltam, a program jól működik. A .hex ből visszafejtve a kérdéses sorokon 6e?? helyén 6e00, c??? helyén c000, f??? helyén f002, 6e?? helyén 6e01 volt. Ez utóbbi érthető, és rendben is van. De akkor milyért jelent meg kérdőjel a .lst filében az változók címeinek helyén? Lényegében azt szerettem volna látványosan kipróbálni az udata_acs hova is helyezi a változóit. Úgytudom access ram....nem ez a kérdés alapvetően, hanem miként foglalják el helyüket a file regiszterekhez képest. Továbbá mekkora maximális res után megadható érték.
Szia!
A hex előállítása több lépésben történik: - asm | c | stb. -> object : Fordítás : Ebben a menetben készül a lista, de kkor még nem ismertek egyes címek a relokálható kódban. - obj -> hex : linkelés : A relokálható modulokat a linker helyezi el a memóriá(k) ban, ekkor kapják meg a relokálható címkék az értéküket. Idézet: Mert nem fordításkor, hanem linkeléskor dől el, hogy mi hová kerül (ebbe az .lkr linker állománynak is van beleszólása...).„miért jelent meg kérdőjel a .lst filében az változók címeinek helyén?” Az udata_acs az Acces Blokk-ban történő elhelyezést írja elő. Mikrovezérlője válogatja, hogy 0-7F vagy 0-5F a Data RAM-ba eső terjedelme. Ennél nagyobb számot biztosan nem írhatsz a "res" után.
Ezt az OSCTUN regiszterrel lehet megtenni, ugye?
Jelenleg nekem a legpontosabb feladat egy szoftveres UART kommunikáció lesz 19200 Baud sebességgel. Ahhoz elegendő lehet az FRC pontossága?
Igen, OSCTUN. A korábban már említett pic24_clockfreq.c állományban ez így néz ki:
A -15 helyett lehet más értékkel próbálkozni... |
Bejelentkezés
Hirdetés |
