Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Talán próbáld meg ezt:
output_high(PIN_B2);// 1 re output_low(PIN_B2);// 0-ra az output_bit helyett.
Hello!
A ccsc-hez nem étrek, de hátha segít hogy asm-ben így kell konfigolni a portokat: Pl.: MOVLW b'00000000' ;összes láb kimenet TRIS GPIO és így tudok ki vagy bekapcsolni egy lábat Pl.: BCF GPIO,2 ;2-es láb 0 BSF GPIO,2 ;2-es láb 1 Üdv!
Legalabb ne rapidshare-es linket adjal meg, mert nem ellopni akarom, hanem informaciot szerezni mi ez... Mi a hivatalos honlapja es ki gyartja?
Salynos ez sem vezet eredményre, pedig az összes többi lábat tudom írni. Esetleg, ha tudod írd be a forrásomat nézd meg légyszíves nálad a mplab simulatorral hátha nálad jó! Kezdek tanácstalan lenni!
Helló eddig én is asm-ben dolgoztam, de nagyon szeretnék c-re áttárni de nem akar össze jönni ennek a lábnak a magasba állítása, a többit tudom setelni csak ezt nem......
Nem fogod ellopni mert már nem forgalmazza a készítője és letölteni sem lehet onnan.
http://www.parsic.de/
Amúgy egy nagyon jó kis program amivel mint logikai kapuk összekötésével lehet a picet programozni.
Hali!
Idézet: „nem forgalmazza a készítője és letölteni sem lehet onnan.” Épp ez a legnagyobb problémája, nem fejlesztik tovább, egy két dolgot én is meg tudok vele valósítani, de ha később 18F-ekkel, vagy fejlettebb PIC-el akarok foglalkozni nem tudok... :no: Ezért próbálom az assemblyt megtanulni helyette.
Csak C-ben nem működik, vagy asm-ben sem.
Voltak egyszer nálam olyan 12F510, 508-as PIC-ek, amiknek nálam sem működtek ezek a lábak. Lehet, hogy hibásak? Idézet: „valamiért a GP2-es portot nem tudom írni.” Programozás előtt el kellene olvasni az adatlapot! Idézet: „If the T0CS bit is set to ‘1’, it will override the TRIS function on the T0CKI pin.”
5.1 PORTB/GPIO
PORTB/GPIO is an 8-bit I/O register. Only the loworder 6 bits are used (RB/GP<5:0>). Bits 7 and 6 are unimplemented and read as ‘0’s. Please note that RB3/ GP3 is an input only pin. The Configuration Word can set several I/O’s to alternate functions. When acting as alternate functions, the pins will read as ‘0’ during a port read. Pins RB0/GP0, RB1/GP1, RB3/GP3 and RB4 can be configured with weak pull-ups and also for wake-up on change. The wake-up on change and weak pull-up functions are not pin selectable. If RB3/GP3/ MCLR is configured as MCLR, weak pull-up is always on and wake-up on change for this pin is not enabled.
Elkészültem a kis kódommal
 A rendeltetése: fordulatszámmérő lesz kocsiba, ami a műszerfal háttérvilágítását fogja PWM módban egy RGB leddel megvalósítani. A probléma az lenne, hogy miután lefut egy PWM ciklus, és ráfut a capturere akkor pont annyi ideig áll, amíg lefut a gyújtás egy periódusa, és ekkor nem világít ugye semmi. Ezt most úgy oldottam meg, hogy addig bekapcsolom az egyik komponenst. Ezt hogy lehetne kicsit komolyabban megoldani? Esetleg egy interrupt? Várom az ötleteket A kód meg elég kusza, rövidebb lesz.
OPTION regisztered hogy van beallitva? Nekem az adatlapbol ugy tunik, hogy bekapcsolaskor az OPTION csupa 1, azaz a T0CS is, igy a GP2 a Timer0-nak a jelforrasa es nem egy I/O lab.
Ja, kozben mar megirtatok
Ezt szinte csak megszakítással lehet megoldani. Egyébként nem sok értelme van a Capture modulnak.
Szerintem nem fontos a megszakítás, capture modul lényege, hogy a processzortól függetlenül működik hardverből. Inkább az kell, hogy a program ne várjon arra egy kis ciklusban, hogy a capture modul befejezze a működését, hanem attól függetlenül kell dolgozni a többi résznek. C nyelven tehát nem írni olyat, hogy while (!CCP1IF) {...}, hanem if (CCP1IF) {...}, és ezt kell betenni a főprogram nagy végtelen ciklusába (ideális esetben csak egy "végtelen" ciklusnak kellene lennie az egész programban). Ha befejezte, akkor ad egy új értéket, onnantól azzal kell dolgozni, de amíg nem fejezte be, addig a régi értékkel kell továbbdolgoznia a pwm résznek. Illetve jó lenne tudni, hogy milyen PIC ez, hátha van másik CCP modulja is, és akkor hardverből mehet a PWM.
Igazad van, nem a "lehet" szót kellett volna használnom. Viszont szerintem úgy érdemes. De van más megoldás is amit említettél, csak ekkor nem kezelődik le az esemény azonnal, csak ha az if-re fut a program. Ha nem időkritikus a dolog, és nincs olyan, hogy nem ér vissza az if-re a szál, akkor működik ciklusban is.
PICkit2 Starter Kit demókártyájának feltuningolása
Készítettem néhány képet a PIC18F14K50 mikrovezérlővel kialakított USB-UART átalakítóról, amelyet a PICkit2 Starter Kit demókártyájának felhasználásával építettem meg. A kapcsolás érdekessége, hogy a VDD és VUSB lábakat összekötöttem, és egy 3,3 V-os feszülségstabilizátorról kapják a tápfeszültséget. Így közvetlenül össze tudom kötni a PIC24-es kísérleti áramkörrel. Ha a feszültségstabilizátort kihagyom, és VDD az USB 5V-járól megy, VUSB-t pedig a PIC18F14K50 belső stabilizátora állítja elő, akkor pedig 5V-os PIC mikrovezérlőkkel kompatibis USB-UART átalakítót kapunk. A PIC18F14K50-be HID bootloadert töltöttem, így USB-ről programozható (ha szükséges). A PIC24HJ128GP502-be is bootloadert töltöttem, így az is újraprogramozható az USB-UART átalakítón keresztül. A PICkit2 egyelőre szabadságra mehet...
Ő, ez nagyon jó. De miért jó a 24F et egy 18F en keresztül programozni ? Akkor már nem egyszerűbb a pickit ?
Nekem elsősorban a kommunikációs lehetőség kellett, hogy ne csak a PICkit2 kezelőprogramja, hanem bármely program tudja fogadni a PIC24 üzeneteit.
Programozni azért kényelmes a bootloaderrel, mert így ugyanazon a vonalon jön a frissítés, mint a kommunikáció, nem kell eszközöket/kábeleket átdugdosni. Másoknak, különösen oktatási környezetben pedig azért lehet előnyös, mert az USB-UART átalakító ára töredéke a PICkit2 programozóénak. Ha egy tanár egy nap alatt egy PICkit2-vel felprogramozza 40 diák PIC24 és PIC18F14K50 mikrovezérlőjét, akkor másnap már 40 diák programozhatja a saját mikrovezérlőjét az USB-UART átalakítón keresztül. Hobbi célokra azért jó a PIC18F14K50, mert olcsóbb és könnyebben szerelhető, mint az FTDI USB-UART chipjei. Csak kell valaki, aki a HID bootloader beírásával megadja az első lökést az induláshoz....
USB-s PIC-el lehet olyat művelni, hogy feltöltöm rá a bootloadert, de a saját programomat asm-ben írom?
Teljesen mindegy, hogy a saját programodat miben írod, végeredményben egy HEX állomány kell, amit a bootloaderrel feltöltesz.
Az a fontos, hogy a bootloader helyét szabadon kell hagyni - ezt testreszabott linker álománnyal, illetve a kezdőcím helyes megadásával szokás megoldani. Idézet: „ezt testreszabott linker álománnyal, illetve a kezdőcím helyes megadásával szokás megoldani.” Sokan nehezen látják ezt át, és ezért nem sikerül a programjuk indítása. Én nem szeretem a bootloadereket, pedig azzal kezdtem a PIC programozást, alig vártam, hogy elfelejthessem. Én csak akkor tenném rá, ha olyan indokok lennének, mint amiket felsoroltál, mert van létjogosultsága, de ezt erőltetni nem hiszem, hogy szerencsés. Egy amatörnek semmi szüksége rá, csak bonyolítja a dolgát(kevesebb hely, figyelni kell a linkelésre, címekre stb.) Kérdeznék is valamit: A HID-es bootloadernek milyen a kommunikációs sebessége? Mert a HID-es interface firmware-nek 64Kbit/sec, ha jól olvastam. A CDC-nek 1Mbit/sec.
MPLAB-ban (asm) hogyan tudok az adatmemóriába (EEPROM) adatokat elhelyezni adott címekre, hogy ezek programozás során bekerüljenek az eeprom-ba?
16F-nél:
18F-nél:
Idézet: „Kérdeznék is valamit: A HID-es bootloadernek milyen a kommunikációs sebessége? Mert a HID-es interface firmware-nek 64Kbit/sec, ha jól olvastam. A CDC-nek 1Mbit/sec.” Ezt igy nem tudom, annyi biztos, hogy a HID Interrupt pipe-ot hasznal mig a CDC Isochronous-t vagy Bulk transfert. Ha jol veszem ki az Isochronous a gyakoribb a viszonylag kis kesleltetese miatt. Az Interrupt transferrel egyszerre max 64 byte-ot, mig az Isochronous-szal 1023-at lehet atvinni full-speed-es eszkoz eseten. Ebbol kovetkezik, hogy a CDC-nek nagysagrendekkel nagyobb lehet az atviteli sebessege. A HID-et nem is azert szoktak hasznalni, mert olyan nagyon gyors, hanem mert szinte mindenutt benne van az oprendszerben a megfelelo driver. Tehat pl a PICkit2-t konnyeden lehet hasznalni emiatt anelkul, hogy barmilyen drivert kellene telepiteni. Most lehet tevedek, de a CDC-nel mintha kellene egy CDC-RS232 emulator drivert telepiteni?
Nekem úgy rémlik a microchip fórumáról, hogy a CDC-nek sem nagyobb az átviteli sebessége, mint a HID-nek. Önmagában az Isochronous képes az említett sebességre, de a rá épülő CDC nem. De lehet, hogy tévedek...
Lehet, hogy tévedek, de a HID interface sebessége szerintem nem 64Kbit/sec, hanem ~64Kbyte/sec (milliszekundumonként 64 byte adatcsomag). Én csak a PIC18F14K50 firmware betöltésére használtam, így nehéz volna megmondani, hogy egy szemvillanás vagy két szemvillanás volt a programfeltöltés.
 A firmware,amit használok, az pedig a CDC serial emulator, ami olyan sebességgel kommunikál, amilyet a Hiperterm, a Bully programletöltő, vagy más alkalmazásban beállítok. PICkit-es tesztelésnél 38400 bit/s lehet a maximum, az ECE3274 kurzus mintaprogramjainál 57600 bit/s a default sebesség, s úgy látom, hogy 230400 bit/s a legnagyobb, amire a programkönyvtár "gyárilag" fel van készítve,s a Bully letöltőprogramban sem állítható be magasabb sebesség újrafordítás nélkül. Idézet: „Most lehet tevedek, de a CDC-nel mintha kellene egy CDC-RS232 emulator drivert telepiteni?” Természetesen nem tévedsz, és köszönöm az infót!
Igazad van, én írtam rosszul , KBájt, és MBájt a mértékegység!
Hogy milyen sebességel kommunikál valójában a PC CDC driverrel, nem tudom, mert úgy tűnik, hogy nem törödik a konfigurációkban beállított értékekkel, de még ezt kipróbálom úgy, hogy beállítok egy olyan alacsony sebességet, amin a most fejlesztés alatt álló kütyü nem lenne képes az adatokat folyamatosan átnyomni. Majd este megírom mire mentem. |
Bejelentkezés
Hirdetés |
