Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Ha azt a kondit nagyobbra cseréled, csak lassabban éled fel, szerintem stabilabb nem lesz.
A 100 nF viszont hiányzik a Vdd mellől.
1. A táp lábról hiányzik a 100n(lehető legrövidebb nyákolással!)
2. A kapcsolók PIC lábairól hiányzik a 100n. 3. Nem látni a stabilizátor IC-t a rajzon. Annak be és kimeneti lábain is közvetlenül kell 100n. 4. pufferelésnek elég az 5V-os oldalon 47uF, max 100uF. A nyers fesz oldalon 1000uF.
Sziasztok!
A ChipCad-nél láttam, hogy elkezdtek valamilyen új SPIFLASH Mbit körüli memóriákat forgalmazni. Szeretnék érdeklődni, hogy használt-e már valaki ilyet? Lehet-e 8bites PIC-kel kezelni? Előre is köszi! Üdv.
Így látatlanban rámerem mondani, hogy lehet. De egy adatlapot linkelhetnél róla.
Szia!
Énis nézegettem ezeket, hasznos jószágnak tűnnek: Bővebben: Link Ami tetszik fícsör rajta az az, hogy két SPI port van rajta.
Köszi a linket! Majd rákérdezek a Chipcadnél, hátha mondanak valami okosat a használatukról...
Szeretném megszakíthatóvá tenni az ICD2 és a pic közötti kábelt, hogy ne kelljen olyan sűrűn ki-be rángatni a telefoncsatlakozót. Melyik lábat kell megszakítani? A Vcc-t próbáltam, de az nem jött be, de nem merek tovább játszadozni, nehogy véletlen tönkre tegyem. Tudnátok segíteni? Előre is köszi! Üdv.
Az MPLAB-ban (ha jól tudom), pont erre való a Release from reset menüpont. Megnyomja az ember, és megtörténik a "kilépés" a reset/avagy programozó módból.
Sziasztok!
Kezdő pic-es vagyok, írtam egy programot, ami természetesen nem működött. Szét szedegettem, hogy kipróbáljam hol a hiba, és arra az eredményre jutottam, hogy nem kezeli a megszakításokat. Egyiket sem. TMR0 által generált megszakítást kipróbáltam szimulálni, tökéletesen működött az MPLAB-ban, de a PIC-be töltve nem reagált semmit. Tudtok nekem segíteni mi lehet a probléma? MPLAB 8.10-est használok PIC16F873A-val IC-Prog 1.05C-vel programozom fel. Előre is köszi Idézet: „Tudtok nekem segíteni mi lehet a probléma?” Hogyne. Így látatlanban a legegyszerűbb, valószínűleg a 13-dik sorban elírtál egy betűt a programban...
Jogos. Bár, azt tételeztem fel, hogy a szimuláláskor előjönne a program hiba. Tehát szerintem máshol lesz. Talán az MPLAB által kreált hex file nem kompatibilis ezzel az IC-prog-gal vagy stb. nem tudom.
Ez egy proba progi, amit direkt egyszerűre csináltam, hogy csak a lényeg derüljön ki, kezeli e a megszakításokat vagy sem. Van benne pár felesleges beállítás, mert az elejét az eredeti progiból kopiztam. Az első megszakításra - mindegy milyen - a cport nulladik bitjét, másodikra a másodikat...negyedikre a negyedik bitjét kéne egybe billentenie. A következőre mindet törli. Indulásnál még a cport7-es bitet beállítja egybe, ez az egy dolog működik. Mellette van az IC-prog beállítása, hátha ott rontottam el valamit.
Mielőtt belemerülnénk a segítésbe, kérlek néhány módosítást tegyél a programban!
1. Ne használj számokat, helyettük használd a bit nevét. Olvashashatatlan így a kód. 2. Használj előre deklarált neveket a kritikus bitekhez. pl. #DEFINE PORTB_INTFLAG INTCON,RBIF 3. Nézz utána az adatlapokban, hogy miként kezelik a megszakításokat. Komplett példa van, csak másolnod kell. A jelenlegi megoldás nem jó. 4. Ettől is egyszerűbb programot írj, ami pl. a Bport hatására egy ledet gyújt ki. 5. Ne EQU-t használj a változók deklarálására, hanem CBLOCK-ot)
Sziasztok! Egy 12F675-ös égetése során problémám akadt, ebben szeretném a segítségeteket kérni. A progi adott. Az égetőm biztosan jó. Az OSC konfiggal szemétkedik. Azt írja "no osc calibration value found". Tudom hogy a progiban a legutolsó értéket kell átírni de már sok fórumban talált értékkel próbáltam és semmi. Nem megy. Pontosabban 3400, 348C, 3470, 347C, 3478. Csatolom a progit is hátha ki tudja valaki olvasni mert én ugyan megtaláltam az OSCCAL szót az asm-ben de nem találtam hozzá tartozó értéket. És ez a szerző oldala. Előre is köszi minden segítséget!
Helló Cpumaster.
A NAGY MESTEREK engedelmével megpróbálom én elmagyarázni neked. Engem már kitanítottak ezzel kapcsolatban. Tehát: Azokban a PIC-ekben, amelyekben van belső órajel, azokat gyárilag bekalibrálják. Ezt az értéket elmentik a memória utolsó címére. (tehát nem a program végén van) Ezzel az értékkel a belső órajel kb. 1% pontosan az előírt érték. Amennyiben neked szükséges a pontos frekvencia akkor ezt az értéket előhívhatod és betőltöd az OSCAL-ba. Ezt a programod elején meghívod (CALL), ekkor elmegy az utolsó memória címre, ahol az első 2 bit az 34. Ez a "vissza" utasításod kódja, majd a második 2 bit maga a kalibrációs érték. Figyelj, mert az MPLAB programozáskor kitörli az egész memóriát, és elvész ez az érték. A PICKIT2 nem bántja ezt az értéket (és ki is jelzi az OSCALL értékét). Amennyiben elveszítetted ezt az értéket a PICKIT2 egyik opciója kiszámítja neked, és be is tölti a memória utolsó címére. Remélem érthető ha nem akkor kérdezz. Üdv.
Sziasztok!
Egy kicsit pontosítanám Sendi válaszát: az oszcillátor kalibrációs értéke a processzor PROGRAMMEMÓRIA-jának utolsó szava, tehát az utolsó lehetséges programszó helyén áll és nem a sima adatmemória helyén. Az értékénél nem az első 2 bit 34, hanem az adott 14 bites processzorra utasításszavára jellemző 8 bit feletti érték ( RETLW --> 110100 (34H) + kkkkkkkk ), az alsó 8 bit (kkkkkkkk) pedig a tényleges kalibrációs érték ( a 8 bites lehetőségből csak 6 bitet használ az OSCCAL!). Tehát a működésnél egy szubrutinhívást csinálunk a programmemória utolsó helyére, ahol egy gyárilag beállított RETLW utasítással találkozik és az így kapott értéket kell betölteni az OSCCAL regiszterbe! Normális körülmények között a programozó készülékek ezt nem szokták felülírni ( a programterület utolsó szavát "alapból" nem írják!) ! Az MPLAB nem bántja ezt a területet alapból!! Bocs a hozászólásért, nem kötekedni akartam, csak ha valaki kezdő és bizonytalan, akkor a pongyola fogalmazás óriási problémákat okozhat neki abban is, amit addig esetleg úgy gondolt, hogy ért! Steve
Szia!
A kapcsolási rajzon kvarc is szerepel! Ha ez igaz, akkor a PIC-nek nincs szüksége az OSCCAL értékre, ha tényleg használja az OSCCAL-t, akkor csak egy sima regiszterként használhatja ( spórol a regiszterek számával!)! Az OSCcal értékének a helyére egyébként "bármit" írhatsz, a működést nem fogja befolyásolni, csak a pontosságot (persze ez érintheti a működést is, de el kell indulnia a programnak!). Szerintem próbálkozz meg a biztonság kedvéért a sima törléssel is, ne csak a programozáskor töröljön a programozó! A RESET beállításod jó ( én úgy látom, hogy külső RESET-et használ, figyelj rá, mert a 12F675 tud belső RESET-et is!)?
Sziasztok! Köszi mindenkinek az építő válaszokat bár elkeserít picit. Egy párhuzamos portos egyszerű TAIT féle programozóval dolgozok. Olvassa is szépen meg minden csak éppen mikor beégetem a progit és visszaolvasom akkor az egész progi memória tele van 0-val. Arra már a google és a különböző fórumok segítségével jöttem rá hogy vigyázni kell ezzel a OSC értékkel és az IC-Prog pedig írja is mindig hogy megváltoztatom? Hát én próbáltam átírni de ellenőrzés után az IC-Prog nem 0-kat hanem egy 0001h hibát dob és kilép. Milyen módja van még az eredeti érték megtalálására mivel nem nagyon szeretnék most még 1 égetőt építeni? Lehet ezt az értéket valami más csellel megtudni? Szerintem bárhogy is írták a progit ez baj lehet hogy nem a saját "OSC value" csücsül rajta a PIC-en. Érdekelne más út is de még próbálkozom hátha...bár a programban valóban van egy OSCCAL nevű konstans bár a definícióját nem találtam. Most lehet hogy hülyeségeket írok csak ezen gondolkodtam hogy akkor azt biztosan valahol egy konstansként definiálták.
Az égető biztosan jó? A programmemória többi részét jól írja-olvassa? Mert ez nem derült ki számomra egyértelműen.
Belepillantva a progiba, én nem látom, hogy az OSCCAL értékét valahonnan be akarná olvasni, csak egy MOVWF OSCCAL utasítás van benne. Tehát nem emiatt nem működik a program. A forráskódban az end sor elé tedd be ezt:
És fordítsd újra. Így már lesz valami a programmemória utolsó címén. Az eredeti értéket lehetetlen megtudni, mert ahogy olvasom, azt egyedileg állítják be minden chipben.
Helló Kissi.
Köszönöm a pontosítást. Mindennel egyetértek veled. Ha azonban megtudnád mondani hogy hol állítható az MPLAB-ban hogy ne törölje az OSCALL értékét, megköszönném, mert nekem kezdettől fogva törli. Köszönettel
Sziasztok
egy kezdő kérdés:mi a különbség az EQU és a CBLOCK direktívák között,és melyiket mikor használjuk? Nekem úgy tűnik hogy mindkettő ugyanazt a célt szolgálja,de javítsatok ki. köszi
Teljesen már szerepük van.
Az EQU konstanst definiál. Ha azt írod, aaaa EQU 75, akkor ahol a programban szerepel az aaaa szöveg, azt a fordító lecseréli a fordítás folyamán 75-re. Ugyanezt a célt szolgálja a #define aaaa 75, és ez utóbbit célszerű használni. A CBLOCK pedig azt csinálja, hogy a mellette álló memóriacímtől kezdődően helyezi el az alatta felsorolt változókat.
Sziasztok! Valaki megörvendeztetne pár olyan programsorral, ami egy PIC kimenetére kötött piezzon rövid pittyenő hangot ad? Mint pl egy telefon, vagy riasztó gombja. Plussz van még egy olyan kérdésem, hogy a piezzo így egy PIC bármelyik cmos output lábán megszólalhat és kell-e valamilyen ellenállás, vagy tranzisztor, stb? Aki nem tud segíteni, vagy csak megintene, az inkább ne írjon semmit, felesleges! Köszi annak, aki meg tud
Sziasztok!
Van egy ASM fájlom, amit megpróbálok átrakni CCS-C-be, és kellene egy kis segítség. Azt szeretném kérdezni, hogy a csatolt fájlban található dolgok eddig működőképesek? Elméletileg még csak annyit kellene csinálnia, hogy jobbra meg balra lépteti a LED-eket a PORTB-n. Ez még készülőben van, csak szeretném, ha valaki megnézné, hogy legalább jó irányban próbálkozok-e, ne a hülyeséggel folytassam. Mindenhez van comment, hogy tudjam, éppen mit akarok csinálni, remélem érthető lesz. Előre is köszönöm a segítséget.
Köszi.
akkor a kettő közül az EQU szerepét rosszul értelmeztem. Így már világos. üdv.
Keresgéltem neten többfele, és találtam pár alapvető hiányosságot az előző CCS-C kódomban.
A kérdésem még mindig az lenne, mint az előbb. Kijavítottam azt a sok hibát, ami az első variációban volt, és kibővítettem pár dologgal.
Az első változatban első olvasatra igen furcsa volt a main hivogatása.
A másodikban attól, hogy az init előre van írva, még nem fog lefutni, csak akkor ha a main-ban meghívod. A main-ban biztos ezt akarod csinálni: amikor a PIN_A0 0 értékű, meghívod az effectselect függvényt, majd break-kel ki is lépsz, pontosabban kilépnél, ha az effectselect nem kerülne végtelen ciklusba. Az pedig végtelen ciklusba kerül, mert a futofenypoz változód 0 értékkel indul és nem is fog növekedni, ugyanis a gombnyomas függvény nem lesz meghívva soha. A futofenyjobb meg bal függvényekben sincs értelme a for(; utasításoknak. Minek kellenek, ha az első lefutás végén itt is break-kel kilépsz a for-ból? Azonkívül, ha megírtad le is fordíthattad volna és akkor kapásból látod, hogy a fordító egy csomó hiba miatt kiabál. Pl.: A define-t nem így kell használni, effectselect függvény sajátmagát is meghívja - rekurzió, ami nem megengedett. Ajánlott a program elején a függvények prototípusát is megadni. Hirtelen ennyi.
Értem, köszi az ellenőrzést.
Azt tudom, hogy az initet nem futtatja le, ha az elejére kerül. A main-ban akartam meghívni, csak úgy néz ki, elfelejtettem beleírni Igen, tényleg elrontottam a gombnyomásás részt, nem is igazán értem, miért 0-t állítottam be kezdőértéknek Lefordítani sajnos nem tudom, mert nincs hozzá fordítóm. Elméletileg javítottam a hibákat, amiket mondtál, csatolva a 3. verzió. Átnézve, a for(; részekre szerintem nincs szükség, ezért azokat kiszedtem. Bekerült 3 új változó: int portb_pos = 0; int portc_pos = 0; int portd_pos = 0; Ezekket még nem használom, de, ha a mostani verzió már jó, akkor már lesz ezeknek is szerepük. A futofenyjobb()-nál található egy portb_pos++, egyelőre még ez sincs használva
Végre sikerült fordítót szereznem, így rájöttem, hogy van még mit javítanom.
Igyekszem kibővíteni a programot a nekem megfelelőre, és remélem azután már jó lesz. Szóval nem kell ránézni az előbb közölt próbámra. |
Bejelentkezés
Hirdetés |