Fórum témák
» Több friss téma |
Hibás a linked!
Egyébként ott van a kész hex is. Mit görcsölsz a fordítással? Csak azt kell beprogramozni és kész. A hozzászólás módosítva: Júl 13, 2015
Valóban rossz a link, bocs. Helyesen Bővebben: Link, majd bal oldalt PIC menü és a legfelső projekt. Szóval mint írtam a az égető programom hibaüzenettel be sem olvassa a HEX-et. Érdekes módon sem a régebbi 350-es és a javított 360-as verziót sem. Pedig más PIC-et gond nélkül tudok programozni.
Mi a hibaüzenet ?
A PK2 azt jelzi, hogy nincsenek a hex fájlban a konfigurációs bitek  , biztos ezért berzenkedik a te égetőd is !
Üdv!
Sajnos ezzel a K150-es progrmozóval sok probléma van (kicsit butácska szegény). Ebben az esetben, valószínűleg az lesz a probléma, amit kissi írt.
A hozzászólásod felett van a hibaüzenet (képfile). Már kb. 5 alklommal futottam neki ennek a projektnek, emlékeim szerint a konfigurációs bitek pótlásával is próbálkoztam, viszont akkor a fordító jelzett több tucat hibát.
Bocs, a képet meg se néztem, valami linket kerestem
!Importáld be a hex-et MPLAB alá, állítsd be alatta a konfigurációs biteket és exportáld a hex fájlt a konfigurációs bitekkel ! Most néztem eszerint az MPLAB-al és az is korrupt CheckSum-ot jelez  ! A hozzászólás módosítva: Júl 13, 2015
Ha csak a CheckSumm a hiba, a gscope350.hex -ben a 91. sor végén a 74 -et kell átjavítani DF -re.
A hozzászólás módosítva: Júl 13, 2015
Köszönöm! Ezt már elfogadja a programozó, be is írtam, ugyan a kapcsolás nem működik. Este rámérek szkóppal.
A hozzászólás módosítva: Júl 13, 2015
Mit kell módosítanom,hogy ne peregjenek a LED-ek?Csak szoftveres mód lehetséges.Ha delay-t teszek a while sor után,akkor meg se szólalnak a LED-ek.Ha egy gomb van,akkor tökéletesen működik.
Az utolso while ciklusban az es (&&) operatort csereld ki vagy-ra (||)
Sziasztok!
Infra távkapcs jelét szerétném feldolgozni egy PIC16F877A van, assembly-ben. Találtam pár mintapéldát, de nem nagyon lettem okosabb. Egy vevő és a hozzá tartozó távkapcs jelét próbáltam PK2 logic analizerrel megfejteni. Ezt mutatja a mellékelt kép. Találtam róla videót is, ott azt mondják, hogy az idő amíg a jel vonalat lehúzva tartja a vevő abból lehet látni, hogy az most logikai 1 vagy 0. Viszont a kép nem ezt mutatja. Ott inkább azt lehet látni hogy mennyi időre engedi vissza magas szintre a jelet. Akkor most hogy kell ezt értelmezni?
Én nem sokat rágódtam, amikor egyszerűbb infra kódokat fogadtam egy PIC10F222-vel. A jelek/ szünetek váltakoznak, az időtartamuk egy bizonyos tűrésen belül állandó. A dekódolás egyszerűen a jel/szünet időtartamának mérése, összehasonlítása a tárolt értékkel. Ez még belefért a programmemóriába.
Az infra jeleket úgy dekódoljuk, hogy ha eltérés van a várttól, akkor a csomagot eldobjuk, és várjuk a következő elejét. Addig csak szemét. Több fajta kódolás létezik. A legjobb, ha az ONsemi weboldalát tanulmányozod, nagyon jó leírásokat lehet ott találni. A hozzászólás módosítva: Júl 17, 2015
Semmi.Meg sem szólal.while nélkül meg össze-vissza villognak.
Sziasztok!
Miért nem tudok változóból értéket átadni az "extern __nonreentrant void _delay(unsigned long)"-nak (pic18.h-ban található)? XC8-at használok.
Ezt a hibaüzenetet kapom: main.c:9072: error: (800) undefined symbol "__delay$0" main.c:9076: error: (800) undefined symbol "__delay"
Nem tudom, hogy XC8-ban mi a helyzet, de általában a késleltető függvényeknek a fordításkor kiértékelhető értéket, azaz konstans paramétert kell megadni.
Ha futás közben változtatható késleltetés kell, akkor írj egy olyan függvényt, amelyben ciklikusan (pl. for vagy while ciklus) hívogatsz egy egységnyi időtartamú késleltetést! Például C18 esetén, 20 MHz-es kvarccal ellátott PIC18-hoz:
Más frekvencia esetén a Delay1KTCYx() paraméterét kell módosítani... Azt ne felejtsük el, hogy a szoftveres késleltetés csak azt garantálja, hogy legalább az adott idő eltelt, de a tényleges késleltetés lehet több is (pl. a megszakítások kiszolgálása miatt). A hozzászólás módosítva: Júl 19, 2015
Köszi szépen a segítséget. Univerzális delay library szerűséget szerettem volna írni és pont amit mondtál, hogy a Delay1KTCYx() értéket változtattam volna változóból a különböző frekvenciákhoz. A változó értékét egy DelayInit függvényben definiáltam volna.
En se vagyok meg jo programozasban, de a ket adatlapot osszevetve, en ugy latom egy 3 bitnyi left shift megoldana a gondot. (hasonlitsd ossze a digital output binary oszlopokat) A legszembeotlobb a -0.5 homersekletnel. Ezek utan latni fogod a tobbi egyezo erteknel is, pl +85, +0.5 stb
Sziasztok !
Lenne egy olyan kérdésem hogy elkezdtem egy ledkocka 3x3x3 méretet de sokaknál láttam ezt a tranyos megoldást a - elvezetésére . Elhanyagolható ez a dolog vagy inkább rakjam bele?? Ha nem rakom be akkor mit von maga után??? Segítséget előre köszönöm
Az attól függ milyen PIC-et és ledet használsz. Meg kell nézni az áramfelvételt, összevetni a PIC terhelhetőségével. Ha a PIC többet tud mint a ledek összes áramfelvétele akkor nem kell a tranyó. Ha kevesebbet akkor kell. Ha kellene és elhagyod jobb esetben csak nem fog működni, rosszabb esetben tönkremegy a PIC a túlterheléstől.
Saggitariusnak igaza van a B20-as 3 bittel nagyobb felbontású szenzor, ami 0.0625 fokot jelent az s20 csak 0.5 fokos felbontású. Megnéztem a programot, nem kell shiftelgetned, mert a programban már benne van, annyi az egész, hogy a TEMP_RES változót átírod 9 helyett 12-re.
Tehát az a sor így néz ki: const unsigned short TEMP_RES = 12;
Ahogy Pali is mondta függ a az alkatrészektől, főleg a LED-től, mert a mikrovezérlők nagy része nem nagyon visel el 1-2x 10mA-nél többet, itt pedig a minimum a 3 LED meghajtása ha jól emlékszem ami 60mA, feltéve hogy teljesen kihajtod a LED-eket. Persze világítanak 10mA-el is meg némelyik még 4-5mA-el is, csak az effektek szempontjából nem mindegy a fényerő.
Én beletenném, hosszabb élettartamú lesz a uC.
Pic16f628 és zöld led 3x3x3 led kockához
Nem volna rossz egy kapcsolási rajz, hogy biztos legyek, hogy egyről beszélünk, de gondolom mátrixba vannak a ledek valamilyen módon. Én a 8×8-as márixot is tranyókkal hajtottam meg, és nem csak az egyik oldalon, hanem a másikon is. De egyik oldalra mindenképp kell, mert megöli a PIC-et. Nem kell túlpörögni a dolgot a legolcsóbb BC337 már nagyon jó ide.
Sziasztok!
A következő lenne a problémám és már a hajamat tépem egy ideje (XC8 a compiler):
main.c:104: error: (188) constant expression required PIC16F1716-be írom a programot, PIC18F2550-be írva ugyanezt, se error és rendesen működött. Ennek így mennie kell, de mégse. A hozzászólás módosítva: Júl 28, 2015
Sziasztok.
Pic18f2550 el olvastam be potméter állását és küldtem el usb-n keresztül egy PC programba. Ez tökéletesen működött amíg az USB HID programot nem Interruposan használtam. Mióta átállítottam hogy USB Interrupt legyen, a Pic megfagy mikor elkezdem az ADC konverziót. Valaki tapasztalt már hasonlót, mi lehet az oka ? (adc.h használom és c18 as fordítót )
Egyre gondolunk
mert nagyon mást pic es led kockát nem láttam 3x3x3 (egyszerű a kapcs)bc182 raktam be
Ha const-nak definiálod a fordítónak ismerni kell az értékét fordítási időben (konstans).
Vagy leveszed a const típusazonosítót, vagy a kivonást futási időben adod meg értékadásként. pl. így:
Az, hogy miért működik a pic18 esetében annak 2 oka lehet, de ezt majd az okosabbak megmondják.Amire én tippelek: - A PIC18 utasításkészlete jóval nagyobb. a standard is szinte duplája a PIC16-osnak, a bővítettről nem is beszélve, így a fordítónak könyebb dolga van. - Az XC8 előtt a PIC18-ra külön fordító volt mint az elődeire, és az XC8 tapasztalatom szerint valami összegyúrt hibrid. A hozzászólás módosítva: Júl 29, 2015
Sziasztok!
I2C-t próbálok beüzemelni 16F877A-n. Régebben ktamás66 tett közzé egy RTC rutint, az alapján idultam el, de néztem több példát is, többek közt EZT a Micrichip bemutatót is, amiben a közölt példaprogram nagy vonalakban megegyezik az említett RTC rutinnal. Szóval a gondom azzal, van, hogy nem akar működni a dolog. A szimulátor szerint a várakozó rutinnal van a gond.
A gond az, hogy hiába adom ki a
Van valakinek ötlete? |
Bejelentkezés
Hirdetés |
