Fórum témák
» Több friss téma |
Az XC hibákat nem értem teljesen. Én amióta C-zek XC8/XC16/XC32 így szépen mindegyiken végigmentem és egyikben én nem igazán találkoztam hibával, bár én nem használok sose ilyen pherip libet meg az ofc-t nem tudom mit jelent, te milyen hibákra gondoltál?
Az X más tészta az tényleg ..., de hát Javás sokat nem kell tőle várni, mondjuk, ha van alatta szekér akkor azzal sincs gond.
A CCS-C parancsok között nem találtam olyant amivel a jelzőbíthez hozzáfénék, ebből (szerintem jogosan) én arra következtetnék, hogy azt automatikusan kezeli. De majd megpróbálom közvetlenül állítani ... talán sikerül!
Hát én is pont ezt szeretném!
Beállítom a Timer2-t ... Engedélyezem a globális megszakításokat ... Bekövetkezik egy esemény, aminek hatására beállítom ( vagy épp nullázom) a számláló kezdő értékét, majd engedélyezem a Timert ... A Timer megszakításban végrehajt pár dolgot, majd tiltja önmagát... és várja hogy egy újabb bekövetkező esemény hatására újból engedélyezzem és tegye a dolgát ... azt várnám, hogy akkor hajtja végre a parancsokat amikor túlcsordul a számláló ... de sajnos nem ... már akkor lefut amikor engedélyezem. Az én elgondolásom hibás? Nem így kéne működnie egy számláló interruptnak?
Ne aggódj, mind így kezdtük..
Lenyúlni meg senki nem fogja, ezek alapok. A regiszterek beállítása pedig nagyon fontos, nem hagyhatod ki vagy hibás instabil működést eredményez. De te tudod..
Nézd meg, milyen utasításokat tesz a kódba a fordítód! Szerepel benne a megszakítási ok (TMR2IF) törlése? Ha nem, írd bele a programba.
Azt hiszem sikerült a dolog ... Néklületek és egy jó logikai analizárot nélkül biztos sokkal tovább tartott volna! Köszönöm!!!
 Milyen szerencse, hogy pár hete már kitárgyaltuk a regiszterek közvetlen elérésének lehetőségét CCS-C alól ... De azért ha kérhetném csekkolja le valaki hogy jól csináltam-e! PIC24FJ256GB106 IFS0 regiszter T2IF bitet töröltem. Headerbe: #word MCU_IFS0 = 0x084 #bit MCU_T2IF = MCU_IFS0.7 main.c-be: MCU_T2IF=0; Sajnos nekem még az angol leírás is kinai, hát még az asm!  A hozzászólás módosítva: Aug 21, 2016
Hátha érdekel valakit.
Gondosabb tanulmányozás után rájöttem, miért van a két láb összekötve. A 629-esnek csak a GP4-en van megszakítása  ezért, ha váltani akarok a programok között, akkor marad a 12 LED-es megoldás. (
Ha a MCLR funkciót letiltod, a MCLR láb bemenet lesz, amit a villogtatási rutinban lekérdezve (prell mentesítve) megoldhatod az üzemmód váltást.
Találós kérdés XC8 1.32-hez (letesztelni vele nem ér).
 Milyen szöveget küldök az LCD-re? Hp41C ki van zárva a játékból.(lcd címzést, delay-eket tessék odaképzelni)
Aztán lehet csak én nem értettem elsőre a miértjét. A hozzászólás módosítva: Aug 21, 2016
Miért???
Egyszer Aignes Szilárddal volt egy beszálgetős műsor, amiben megkérték, jósolja meg milyen idő lesz akkor, amikor leadják a rögzitett felvételt. Egy kérdése volt: Hány órakor kezdődik majd. Este 8 -kor. Aigner válasza: Sötét lesz. Az első 4 karakter: "text" Egyébként warning -ot kellene kapnod: 4. sor: Van olyan ág a függvényben, aminél nincs megadva a visszatérési érték.
Én már elkészültem a saját verziómmal, és igazolódott az alapfeltevésem. Ha egyszerre csak egy ledet akarsz kapcsolni, gond nélkül megy a 20 led, és a program sem túl bonyolult. De ha (látszatra) többet, akkor már multiplexelni kell, és ott már túl sok a 20 led. A 12-vel megy szépen.Bővebben: Link
Ha a főprogramod mSec nagyságrend környékén pörög, és csupán emberi reflex sebességű, amit vizsgálni akarsz, semmi szükséged a megszakításra. A 20 led maradhat.
Most erre reagálva jól be kellene másolnom a több ezer soros LCD könyvtáramat is, mert ugye fő a pontosság és anélkül nem lehet megérteni a feladatot.
 Úgyhogy troll off, please!!!Kapok is, de attól még egy standard fordító nem így működik. Értelemszerűen 0-val kellene visszatérnie ha nem teljesül a return 1-hez szükséges feltétel. Márpedig itt nem teljesül, mivel a blokkból kilépve megszűnik a var változó, így a következő híváskor az x = 0 miatt nullát kellene felvennie és nullával visszatérnie. De nem ezt teszi. Onnantól meg hogy leírtad a hibát, értelmetlenné vált a fejtörő másoknak.
Üdv. PIC18F46K22 belső eeprom írásakor mennyi időt kell várni írásra, nem találok adatlapon erre utalást. A régi pld. 16F648-nál 20ms volt, talán a 18F46K22-nél is annyi?
Köszönöm.
Szegény Szilárd nem "Ágnes" volt, hanem Aigner. Ha már nincs az élők sorában, legalább a nevét írjuk le pontosan..
Köszönöm az észrevételt... Másodszorra jól írtam.
Idézet: „standard fordító nem így működik” Mit nevezünk standard-nak én mikor szóba jön a X vagy fordítók mindig a VS C#/C++, hozom elő ott nem warning-ot kapsz, ha csak if ágból return-ölsz hanem errort, persze egy gép nem egy PIC, de nekem a VS az etalon , de mibe tart odaírni, hogy else retrun 0; vagy, ha több érték van egy switch és a case-ek be return val;és a switch után vagy default-ba return 0; Persze ezt lehet megteszik helyetted a szuper okos fordítok CCS/MikroC stb..., de ez ha tudod mit akarsz (nálam) azt szokta csinálni amit kell.
Kadarist szólt, hogy inkább itt tegyem fel a kérdésem, ne a Elektronikában kezdők kérdései-ben.
Egy 3.3V-os PIC32-höz szeretnék illeszteni egy AD9850-est (ebay). Az ebay-es verzióban 125MHz-es kvarc van és a dds csak 5V-on tud működni 125MHz-en, de 5V-on 3.5V a logic low. Én arra gondoltam, hogy egy I2C Level Shifter-ből kiindulva raknék három ilyen FET-es illesztés a D7, W_CLK, FQ_UD lábra de a low side-os 10k-ot kihagynám ez így működőképes?
Szia!
Mindegyikre kell szintillesztés,mert 3,5V-tól garantálja a magas szintet 5V-nál. Az FQ_UD-re kell majd felhúzó(kb. 10k,az 5v-os részen),bár lehet,hogy a panelen már van,így panel alapján nem tom. És a reset is ki van vezetve,arra figyelj!.
Az említett modul oszcillátora 3.3v-os. Szinte egy-két hónap után tönkremegy, ha 5 voltról járatod, ahogy azt már többen leírták. Illetve én is ezt tapasztaltam. Az egész modul egyértelműen 3.3 voltos rendszerhez készült, csak hát úgy nem lehet eladni az arduinohoz...
Az AD9850 3.3 voltról pedig vígan elmegy akár 150MHz-en is tapasztalataim alapján.
UART kommunikációval kapcsolatban kérdeznék ...
PIC24 hardweres port. Amíg adatokat küld a PIC , addig leáll a főprogram futása, mindaddig amíg az összes adatot ki nem küldi. Gondoltam azért mert nincs beállítva puffer ... Viszont, ha beállítom, hogy legyen adási puffer, akkor meg nem küldi ki az adatokat a vonalra. Mikor üríti a PIC a puffert? Ha megtelt? Ha bejövő puffert is beállítok akkor mikor keletkezik megszakítás?
Mit értesz az alatt, hogy legyen adási puffer? pl.: az UART modulban van egy FIFO, vagy DMA.
Ja akkor te ilyen okos fordítót használsz.
Az a baj, hogy én ezt a fordítót nem ismerem, de nagyon sokféleképpen meg leget oldani a dogot, hogy ne fogja a vegyen el időt a főprogramtól. A legegyszerűbb, ha fogsz két tömböt és az rx és tx if-et nézed megszakításban mikor rx/rx if van akkor a bufferba ba beírod az adatot (persze a tömbön kívülre mutatást, main ne férjen hozzá ha adat mozog stb.. ezeket le kell kezelni). A másik lehetőség nem tudom milyen PIC24-et használsz, de esélyes, hogy van benne DMA azzal a legegyszerűbb és apróbb időpillanatokon kívül nem is fogja a processzor időt. De, ha van is DMA a PIC-ben az nem tudom hogy néz ki kódilag CCS-ben. Nem akarok beleszólni, de biztos, hogy ez a fordító a tuti, kicsit arduinos csengése van... Ha csak hobbi nem szóltam, de ha valami komolyabb szerintem mindig az a legbiztosabb, ha te írogatod a függvényeket, mert az tuti, hogy azt csinálja amit kell. Persze ez csak személyes vélemény, úgyhogy ha neked ez tetszik használd "egészséggel" A hozzászólás módosítva: Aug 22, 2016
Hát az a 256 az igencsak szoftveres buffer, mert a pic24-esek hardveres FIFO-ja emlékeim szerint 9 bites és 4 szint mélységű( 5 a TSR regiszterrel együtt) és bájtonként mindend stop bit után küldi az adatot, illetve TX regiszterbe való töltés befejezéséig nem indul.A szoftvereset meg úgy tudod kihámozni ha átnézed az általad használt fordító könyvtárát és kimazsolázod belőle a működését. Ezt az "Amíg adatokat küld a PIC , addig leáll a főprogram futása" dolgot nem egészen értem, mert akár buffer nélkül is meg lehet oldani, hogy menjen addig a főprogram, ha figyeled megszakításban, hogy mikor lehet a következő adatot tölteni, persze nem tudom mennyi adatról van szó, és közben mit kell csinálni még a PIC-nek. Ehhez viszont meg kell írnod a saját UART kezelő rutinodat, és nem a ki tudja hogy működő beépítettet használni. Ha még mindig PIC24FJ256GB106-ról van szó sajnos abban nincs az UART-nak DMA elérése.
Kezdek rájönni nem is zavar annyira, hogy kommunikáció közben a PIC nem csinál mást!
Csupán kicsit érdekesnek találtam, hogy hardveres UART esetén is lefogja a PIC-et. Ha ezt a CCS fejlesztői nem oldották meg, szerintem én sem fogom ... legalábbis egyelőre!
Sziasztok.
Megépítettem Ezt az órát , működik szépen, csak valami nem stimmel a programban, mert 19:59 után nem 20 órát mutat, hanem 00-át és akkor vált át AM-ről PM-re, de a perceket jól mutatja tovább. Aztán reggel 6 órakor már jól mutatja az időt, és a dátum is jó. (Nem tudom mikor vált vissza, talán éjfélkor) Valaki segítene, hogy mit kellene átírni a kódban, hogy jó legyen és az " AM PM" sem kellene a 24 órás megjelenítéshez. Köszönöm előre is.
Lenne egy kerdesem LCD-vel kacsolatosan. El tudna magyarazni valaki, a microcontroller hogyan tudja kezelni az LCD-t? Az odaig vilagos, amikor definialjuk a vezerlo vonalakat, de az adatvonalakkal mi a helyzet? Ertem en ez alatt, megadjuk melyik port, de nincs semmi mast, pl azt sem, hogy 4 vagy 8 bites modban hasznalom az LCD-t.
Ha valaki nagyon specifikus akar lenni, XC8 forditot hasznalok, peldakent lehet emlegetni 18F vagy esetleg 16F controllereket, LCD alatt valami egyszeru 2*16 vagy hasonlo alfanumerikus kijelzot ertek. |
Bejelentkezés
Hirdetés |
