Fórum témák
» Több friss téma |
Fórum » CCS PIC Compiler
Az includolt 24512.c-t nem tetted fel. Ha a "gyári" includ fájlt használod, (drivers mappa) akkor nem kell bonyolítani, abban az eeprom írása és olvasása benne van, csak az I2C vonalait kell beállítani. A PORTA digitálisra állításáról se feledkezz meg!
Mindezek alapján itt a kód:
Köszi MPi-c ! Így már működik, de a 24512 include-t átnézve már rájöttem a hibámra!
Az általad küldött kódba felesleges a delay mert az include-ban while-al figyeli hogy befejeződött-e az írás.
Csak nem tudom a jeleket rendesen fogadni a piccel. Valaki megtenné, hogy átnézi ez alábbi fájlt, hogy vajon mi lehet a hiba?
Az analizálandó jelsor a következő: jelsor A függőleges osztás 200us. Egy 1-es min 5-600us magas, a nulla ugyanez csak alacsony szint. Minden felfutó élre kellene figyelni, itt kezdődik egy bit. Az első felfutó él utáni hosszabb szakasz a stratbit. Ezután jön a 8 bit. Ha a magas szint a hoszabb, akkor 1, ha az alacsony szint tart tovább, akkor 0 a bit. És ezt kellene nekem usb-n elküldenem a pc-nek. A jelforrás egy tolatóradar, amit a kocsimba akarok rakni, a carpc-hez illesztése miatt kellene ezt megoldanom. Előre is kösz a segítséget.
helyett ezt írd:
Ezt is kipróbáltam, és kicsit át írtam, de még most sem jó.
Adat helyett, egy 4-est kapok vissza. Valami nagyon nem jó. Az átvitel jó, a 255-ös számot megkapom, ezért is írtam bele, mert már azt hittem, hogy a kommunikációval van valami. De ezt a 4-est nem tudom hová tenni. Próbáltam változtatni a számlálásom is, átírtam a számokat, de semmi ugyanúgy 4-est kapok. Valamit nem jól állítottam be, vagy a kód nem jó?
Két lemenő él közt eltelt időt szeretném megmérni a következő kóddal, de rendszerint a második while ciklusba beragad. A figyelt lábra időnként 5 vagy 10ms időközönként érkezik impulzus (egyszerre egyik, pont azt akarom felismerni, hogy melyik), rendszerint akkor van baj, ha folyamatosan kapja a lemenőéleket.
Hogy ragadhat bele, ha a hardveres timerrel mindenképp kilököm?
Na az előző gondom megoldódott, hardveres gond volt...
Új dolog, amit nem értek: 18F2553-nál valami nem jó az órajellel. Próbáltam 20MHz, 40MHz kvarccal, belső órajellel, de az uart kapcsolat mindig rossz maradt. Amikor 19200 baudra állítottam, 4800-ra kellett állítani a hyperterminalt, hogy megjelenjen az adat. 18F piccel még nem játszottam, configban itt valami más lenne, mint a 16-osoknál? Ezek a beállításaim, gondolom ott a hiba:
CCSC súgó szerint vagy így adom meg az órajelet (HS, és 40M) vagy azt mondom, hogy 40M, oscillator, és akkor a fordító helyre teszi a HS fuse bitet magától. Úgy sem működött jól. A program fut, irkál mindenfélét, de nem értelmes karakterek.
40 MHz-es kvarccal ne próbálkozz, nem fér bele a specifikációba! 20 MHz-es kvarc esetén 1:5-ös előosztót kell beállítani (CPUDIV=5, nem tudom, hogy mondják ezt CCS-ül), be kell kapcsolni a PLL-t (HS helyett HSPLL), és nem kell leosztani a kimenetet (PLLDIV=1, vagy ahogy hívják). Biztosan találsz 18f4550-hez mintaprogramot, annak alapján kell konfigurálni.
Az órajel nem 40 M, hanem 48M lesz (legalábbis remélem).
Nem megy; 4550-re a gyári példák közt azt mondja, hogy 20MHz kvarchoz a következő való:
Ezzel sem jó. Nem értem, hogy számolja az órajelet. Ha PLLx és CPUDIVx dönti el, hogy mit kell nekem beírnom, hogy jön ki ott 48 (illetve nem jön ki mert nem megy vele)?
Valószínűleg PLL5 jelenti az 1:5 előosztást (mindig 4 MHz-et kell adni a PLL bemenetére). A PLL ebből 96 MHz-et állít elő, s ennek a felezéséből (CPUDIV1, USBDIV) áll elő a 48 MHz a CPU és az USB SIE számára.
Kvarccsere esetén a fentiek közül csak a PLL5-öt kell átírni, a többit nem érdemes babrálni. PLL1 4 MHz-es kvarchoz PLL2 8 MHz-es kvarchoz PLL3 12 MHz-es kvarchoz PLL4 16 MHz-es kvarchoz Helyesbítés: Amit előző beírásomban tévesen CPUDIV-nek írtam, azt PLLDIV-nek kellett volna mondanom.
Ha tehát ez nem működik, akkor kuka... 4MHz kvarccal próbáltam:
Tegyél már be egy
sort a késletetés után, és számold meg, hogy mondjuk 10 másodperc alatt hányszor villog a LED! Természetesen d0 helyett írj egy olyan lábat, amelyik digitális, és LED van rajta.
Hát ez 20 alkalommal vált állapotot, eszerint meg jó az órajel.
(Közben nem jön semmi. hyperterminal jól van belőve, az is 19200 8-N-1; próbáltam PK2 UART toollal, annak sem tetszik.)
Mellékelek egy bugyuta demót, ennek mennie kellene 19200 bit/s sebességen, 4 MHz-es kvarcot feltételezve. Ha véletlenül zagyvaságot írna, próbáld meg reset után is újra!
EJNYE. Nem printf, hanem fprintf. A printf nem érti, ha a kiírandó dolog elé stringet írok. De a fordító ki nem nyögné, hogy neki az nem kellett oda... 1db f betű szerezte az örömöket.
Egyébként a mellékelt .hex is működött, köszi! Idézet: Már miért ne értené? Lásd pl. itt:„A printf nem érti, ha a kiírandó dolog elé stringet írok.”
Szerintem stream-et akartál mondani, az tényleg nem kell neki. Most kapartam elő egy régi programomat (PIC16F690-re készült), s abban én nem is definiáltam stream paramétert. Gondolom, hogy a CCS C-nél is a soros port az alapértelmezett kimenet.
Elírtam valóban. Mikor a #use RS232-ben megadom, hogy stream="mi legyen a neve", azt nem használhatom ott.
Ha csak egy stream van, akkor nem is kell. Az fprintf-re szerintem csak akkor van szükséged, ha váltogatni akarsz a stream-ek között.
Sziasztok!
Valaki használt már MAX6957 -os ledmeghajtót? Két napja küzdök vele és még semmi.
Infra távirányító jelet szeretném fogni.
Találtam is egy jónak tűnő kódot hozzá, de sajnos valamiért nálam nem akar működni. Az egyetlen eltérés hogy az eredeti kapcsolásban TSOP1738-at használnak, ami sajnos nekem nincs én TSOP1736-al próbálom, de emlékeim szerint egyszer valamikor régen egy ilyennel csináltam egy infra vevőt és az működött. Szóval, ha valaki tudna segíteni, azt megköszönném! Bővebben: Link
Lehet, hogy nem a kódban vana hiba. A TSOP17xx utolsó két számjegye az infra vevő frekijére utal. Pl. TSOP1738 az csak 38kHz frekit vesz. Mást nem!. Lehet, hogy a távirányítód nem ezen a frekin megy. Nézd meg szkóppal, vagy logikai analizátorral, a kimenő jelet.
Sajonos megmérni nincs lehetőségem most, egyébként az itthon található összes távkapcsolóval probálom.
De ha rámérek a TSOP1736 kimnenetére miközben kapcsolok, változásoka azért látok.
És konkrétan mégis mi a gond vele? Két napja nem sikerül beforrasztani?
A probléma ott van hogy amikor érkezik egy jel az infrától, lenullláza a T1-et és méri milyen hosszú a jel.
Csakohogy valamiért itt mindig 0 a t . Az printf(.... sort beszurva láttam hogy ez a gond. Ha ezt a részt modosítom ( return 0 kitörölve) akkor már néhány gombot stabilan felismer, de sokat nem. Az a kérdés hogy mért nem müködik a timer1() mérése ? Mért kapok ott mindig 0 értéket ?
Valamiitt nagyon nem kerek!
Az rc5 az 36khz-es, ha a progi 38khz-es vevőt támogat, az akkor nem rc5, legalábbis szeerintem. Ezen a linken meg tudod nézni, hogy milyen frekikhez milyen kódolást használnak. Bővebben: Link Ebből láthatod, hogy valami nem igazán stimmel. Ez egy rc5 vevő prog, bár kicsit bugyuta, de működik:
Az RC5 szabvány nem az infra vivőfrekijét rögzítette, hanem a kódolási információkat, protokolt. Bármilyen vivőfrekivel mehet az információ. Én úgy csinálnám, hogy megmérném a START bit szélességét, hogy tudjam, milyen a bit szélesség. Ezáltal máris független a program a különböző gyártók által használt bitsebességtől. (tudni illik, hogy a jel 32 vivőfreki periódus és a mögötte kötelező szünet is 32 vivöfreki periódus husszúságú). Minde bitben van egy élváltás, és az élváltás utáni állapot hordozza az információt. Tehát az élváltást kell megvárni és utána fél bitszéleségnyi idő múlva be kell ovasni az infra bemenet állapotát. Ennyi.
Itt minden tudnak az infrás távirányítókról. Bővebben: Link
Lehet, hogy tévedtem, és tényleg nem fontos a vivőfreki, viszont a linkelt oldalad, az ugyanaz, amit én is linkeltem.
 És ezen az oldalon 36khz-esnek írják a Philips rc5-öt. Akkor most hogy is van ez? 
Most látom, hogy az eleje lemaradt a kódnak.
 Ez kell még hozzá, hogy működjön is.
Valószínűleg rosszul értelmezted a leírást. Nem a frekihez van választva a kódolás, hanem, hogy milyen kvarcot találtak a fiókban a gyártónál. Attól a kódolás még RC5-ös. Én már találkoztam 56kHz és 32kHz vivőfrekis RC5 kódolású távirányítóval is, mint két véglet.
A progidhoz még annyit írjál légyszíves, hogy milyen PIC-et használsz. |
Bejelentkezés
Hirdetés |
