Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Szerintem nem ellenkezik a Hi-Tech felvásárlása azzal, hogy más cégek C fordítót készítenek. Hi-Tech felvásárlásával lett nekik egy saját fordítójuk a kisebb picekhez, teljes termékpalettát le tudják fedni saját C fordítóval. Viszont a lehetőség továbbra is megvan, hogy más készítsen C fordítót, és valaki azt használja.
A Hi-Tech ingyenes? Úgy tudom igen(nem használom), csak a C18 teljes verziója nem az, viszont a nem teljessel is lehet dolgozni, mert én nem sok eltérést láttam a kettő között futási teljesítményben, csak méreben...
Nem ingyenes a Hi-Tech sem, csak van belőle ingyenesen használható Lite verzió. Na de az azért néha nem semmi kódot gyárt, volt itt egyszer szó róla, hogy nem ment az EEPROM írás, és azért nem ment, mert a Lite verziós fordító direkt rakott be plusz értelmetlen utasításokat...
Ez az egyszerű parancs miért nem akar működni?
FSR1 és FSR0 fizikai regiszter nem létezik. Van FSR0L, FSR0H, FSR1L és FSR1H, ezek között tudsz adatot mozgatni. Próbáld így:
movff FSR1L, FSR0L movff FSR1H, FSR0H Idézet: Működik az, csak nem azt csinálja,amit szeretnél. Ha megnézed, hogy ezek hogy vannak definiálva:„Ez az egyszerű parancs miért nem akar működni?”
akkor rájössz, hogy mi a baj. Az FSR0, FSR1, FSR2 csak a LFSR utasításban érdemes használni. Ha a mutató által címzett tartalmat akarod mozgatni, akkor movff INDF1, INDF0 kell, ha pedig magát a mutatót akarod másolni, akkor
kellene.
Direkt? Na azért ez már túlzás! Biztos vagy benne?
Nézd meg magad is, itt van a kezi.lst-ben: Link
Hat ezt termeszetesen nem lehet bizonyitani. De amikor bele rak 3x egymas utan banksel-t szinte minden utasitas ele es ehhez hasonlatos dolgokat muvel akkor azert elgondolkodik az ember
Magát a mutatót akartam másolni, köszönöm mindkettőtöknek a felhomályosítást!
Csak most tudtam foglalkozni a problémával. Kipróbáltam az oshon féle szoftvert, be se tudja olvasni a pic tartalmát, üresnek véli. Programozás során szintén a 0. helyen hibát ír. Feltöltöttem a picet egy bitmintával is, de semmilyen változás nem történt, visszaolvasáskor a régi programot kapom vissza. Közben tudtam kölcsönkérni egy PicKit2-t, az is üresnek nézte, nem tudott bele írni semmit.
Belső óráról járatom a PIC-et az áramkörömben, a Timer1-et viszont külső órakvarcról hajtom, és most hogy jobban megnéztem az adatlapot, arra gondolok most, hogy kizártam magam a picből. A figure 5-15-ön van egy olyan kapu, ami letiltja a "serial programming input" vonalat. Lehetséges, hogy programozás előtt beindul a PIC, és beállítja a Timer1 oszcilátorát, amivel tiltja a programozás bemenetét?
Nem lehet kizárni magad, hacsak a PGD, vagy a PGC láb nem ment tönkre. Ha a PK2 nem tudja írni, akkor annak a PIC-nek lőttek!
Watt mesternek tokeletesen igaza van. Problemak persze lehetnek, pl. ha bekapcsoltad a program vedelmet akkor nem tudod kiolvasni, es irni is csak ugy ha torlod a teljes PIC tartalmat eloszor.
Masik problema, hogy ha arra gondolsz az a problema, hogy a programozas elott beindul a programod es az valahogy befolyasolhatja a programozast, akkor meg kellene probalni a "Vpp first" modot. Azaz meg mielott a PIC elindulhatna az MCLR-t felhuzza programozo feszultsegre, azonban ehhez a programozonak kell biztositania a tapot. Ezt nem tudom a Te programozod tudja-e, PicKit2 tudja...
Én a minap néztem újfent meg ezeket a C fordítókat, el vagyok keseredve. Ami ingyenes, az nem használható, ami használható, az többszáz dollárnál kezdődik. Egyszer még a végén írok valami fordítót magamnak (lehet, nem C lesz, de saját és ingyenes)...
A HiTech-nek egyébként inkább a 18F-es verziója által gyártott kódot érdemes megnézni a lite módban működtetett pro verzió esetén, az valami botrány (több movlb minden egyes utasítás előtt). A 16F még talán használható is kisebb dolgokhoz, de nagyon észnél kell lenni a kritikus utasításszekvenciáknál, ahogy potyo is írta.
De mintha az SDCC valamennyire azert hasznalhato lenne? A JAL-lal meg csak az volt az egyetlen hatrany, hogy nem tud float-okat kezelni, vagy volt valami mas nyug is?
MPLAB alatt a debug nekem nem megy SDCC-vel. A JAL (úgy látom) nem tud relokálható módon fordítani és szintén nem lehet a kódot debugolni. Ami debugolható is, és valamennyire használhatónak is tűnt, az a CCSC, de az meg pénzes.
A JAL egyébként szimpatikus lenne, ha pl. MPLAB alá integrálható lenne és ha tudna valahogy több modulból, relokálható módon előállítani kódot. Egyébként a jelenlegi állapotában is komoly vetélytársa minden pénzes megoldásnak, de a debugolhatóság hiánya szerintem eléggé visszavesz a "használati értékéből".
Hat ebbol a szempontbol az AVR jobb, merthogy ott a gcc. Nyilvan az sem tud olyan jo kodot csinalni mint a penzes fordito tarsaik, de azert eleg szep kodot general az is. Raadasul meg Ada is van hozza.
Amugy meg kellene nezni, hogy SDCC ill. JAL-t meg lehetne-e fejelni a debug es relokalhato kod modositassal. Talan konyebb, mint teljesen elolrol kezdeni egy forditot. Mi a velemenyed?
A JAL-t mindenképpen érdemes lenne, az SDCC nagyon bonyolult projekt, abba én nem nyúlnék bele. Akkor már inkább valami saját minimál C fordító, ami eleve MPLAB integrálhatósággal indulna. Nem a nyelv hiper-szuper kiforrottsága az, ami hiányzik (ebből a szempontból a JAL nagyon szimpatikus), hanem a használható környezet.
Idézet: A SourceBoost C fordítót nézted már? Nem tudom, hogy milyen minőségű, de a Full verzió $70, a Pro verzió meg $145. Nem egy ökör ára... Ingyenes verziója méretkorlátos: 2 Bank/2K PROM (PIC18-nál 2 Bank/4k PROM). „Ami ingyenes, az nem használható, ami használható, az többszáz dollárnál kezdődik.”
Igen, a minap feltettem az MPLAB alá, de még nem volt rá időm, hogy foglalkozzak vele. Egyébként az árait én is szimpatikusnak találtam, ha használható a környezet és a kód, amit csinál, akkor ez talán még bevállalható hobbista szinten is.
Hát talán rá lehet mondani, hogy ilyet véletlenül nem csinál egy fordító, de a fene tudja. Lehet, hogy van olyan C kód is, ami nem okoz ilyen szerencsétlenséget a végén. Ezt talán csak az tudja aki tervezte!
Programvédelem nincs bekapcsolva.
Idézet: „hogy ha arra gondolsz az a problema, hogy a programozas elott beindul a programod es az valahogy befolyasolhatja a programozast” Pont erre gondoltam... Sajnos az égetőm nem tudja az MCLR-t felkapcsolni a VCC nélkül, és resetben se tudom tartani a picet, mert az MCLR funkció tiltva van, bemenetként használom azt a lábat. Ha hozzám kerül megint a Pickit2, még próbálkozom, az eddigi segítséget köszönöm. Idézet: „mert az MCLR funkció tiltva van, bemenetként használom azt a lábat.” És az áramköröd ezen része elviseli, ill. nem terheli a 12V-ot? Mi van az PGD,PGC lábakkal, azokon is van valami? (Ilyen fontos részleteket nem valami szerencsés elhallgatni, mert a válasz ezek tükrében lehet helytelen is. )
Sziasztok!
Tudom, hogy volt mar ilyen kerdes, de konkret valaszt nem talaltam. Mar napok ota egy rotary mechanikus encoderrel kinlodok, de sehogy sem sikerul tokeletesen beuzemelni. Probalkoztam kulso megszakitasbol kezelni, valahogy igy:
Ezzel az volt a baj, hogy lepesvesztes tortent, mindig egy par fordulat utan tevedett. Olvasgattam itt a forumon, hogy interrupt nelkul is meg lehet csinalni, pollingolni kell, igy hat azzal is probalkoztam:
Ezt a fuggvenyt 5ms-onkent hivom meg (igy elvileg a perges is meg kellene oldodjon). A problema itt is az, hogy nem mindig veszi figyelembe, hogy fordult az encoder. Ha lassan forgatom akkor megy ha kicsivel gyorsabban akkor mar nem. Azt elfelejtettem mondani, hogy az encoder felbontasa 24, amit szoftveresen szeretnek megduplazni (lathato, hogy a lemeno es felmeno eleket is figyelem). Igy meg ha kezzel forgatom is, tul gyorsan tortenik meg a lefuto es felfuto el. Varok minden hozzaszolast, foleg azoktol akiknek sikerult megoldani ezt az encoderes dolgot.
Interruptban semmikepp se csinalj kenyszer varakozast!
Amugy kellene egy kis matek: 1. Mekkora a max fordulat amit merni szeretnel 2. Ugye azt fel kell szorozni 24-el... 3. Tehat akkor mekkora az egyes erintkezesek kozt eltelt ido 4. Ehhez kepest mekkora a perges ido Ezekbol kiderul egyaltalan meg lehet-e valositani amit szeretnel.
Az a DelayMs(1) kinek a tiszteletére van ott? Gondolkozz úgy, hogy nem használod Delay és társait.
Eloszor is kosz a gyors valaszt!
Tudom nem illik megszakitasba delay-t tenni, de kenyszermegoldasbol tettem csak. Na mar most, nem fordulatot szeretnek merni, hanem egy lepteto motorrol visszacsatolast. A motor tekercsei 10ms-onkent vannak vezerelve, magyaran 10ms-kent lep egyet, tehat 125rot/min a max fordulat. Az encoder max eloirt fordulatszama 120 rot/min, de szerintem az meg belefer Esetemben tehat 20ms alatt lepne egy poziciot az encoder, vagyis 10ms alatt fordulna egy fel poziciot ami alatt ad a CHA egy lefuto vagy felfuto elet. Adatlap szerint max 5ms a perges 15 rot/min eseten. Tehat az is belefer a 10ms-ba. Mondjuk azt nem tudom, hogy ha no vagy csokken a fordulat az mennyire befolyasolja a perges idejet.
Azt persze elfelejtettem mondani, hogy a lepteto motor lepesszoge 7.5 (tehat 1 fordulathoz 48 lepes szukseges)
Sziasztok!
Van két darab PIC16F877-m és egy 4 MHz-es kristályom, az lenne a kérdésem hogy lehet azt megcsinálni hogy egy közös kristályról járjanak a két PIC? Van valamilyen kapcsolás erre? smrtln
megcsináltam az elektronikus dobókockát de a pic be nem tudom a programot beirni mert nem fogadja el valami hibás a hex programmal valaki megtudná nézni nekem én nem értek a programozáshoz de a gyerkőc már nyagat itt ,hogy mikor lesz már kész
|
Bejelentkezés
Hirdetés |