Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Például.
Mondjuk leginkább angolul tud...
Igen, ezt szeretném. Azt mondom: be, ki, állj, stb. és végrehajtja.
Egyrészt ehhez a feladathoz egy mikrokontroller olyan, mint téli hóviharban egy lepkeszellentés, másrészt a beszédfelismerés nem olyan egyszerű, hogy egy délután alatt össze lehetne dobni. Ha belátható időn belül akarsz végezni, ezt keresd (pl.): speech recognition raspberry pi.
Ugyan nem PIC, de kész modul formájában ez a legegyszerűbb. Egy PC-s szoftverrel az adott kimenet aktiválására bármilyen parancsszót eltároltathatsz vele. Alapvetően jól működik, de nekem volt olyan amikor elsőre nem ismerte fel a kimondott parancsot...
16F programba írt verzióadat RAMba nem dolgozható fel ?16F84A nál, ha a programba beírok PRG.verzió adatot, akkor azt a futtatás alatt le se tudom hívni ?PDF ben látott minimális utasításkészletből semmi nem sejtet, hogy elérhessem. 18F nél a TABLAT ot szoktam meg erre a célra.
RETLW utasításokkal lehet a ROM-ban tárolt tömböket elérni.
Ebben van rá példa a 28 (15). oldalon. Nem túl 'felhasználóbarát' módszer, de nincs más.
Köszi a választ. Nekem éppen PIC-re kell.
A videóban PIC16F946 full protect file kilocsolása.
1 fálj lesz a legvégén az eeprommal, ami előtt a flash. Mivel itt már a PK3 van megtrükközve, így a TTL-nek csak egyszerű munkája van. Mondjuk nem értettem a Chiperase miért nem használja azt a módot, amivel 1 utasítással töröl mindent. 1db 6 bites parancs képes Prg, Eep, Cfg, UserId törlésre. A csak Cfg erase CP=1 CPD=0 módban feloldja az eepromot, de ilyen protect módú chipet biztos nem találunk eszközökön. A hozzászólás módosítva: Dec 17, 2024
mi történik, ha RETLW kevesebb mint a a lehetséges PCL hozzáadása ?Mi történik, ebben az esetben ?Nézek egy PIC 18F programot melyben furcsa dolgot látok. A hivatkozott RETLW s subban 16darab RETLW van, ezt más függvény követ. kiolvas byteot, ANDLW 0xF el vág, RLNCF f=E8(=WREG) d=1 a=0, és meghívja a RETLW s subrutint. Azt furcsálom, ha 4 hasznos bitre megvágja, majd balra eltol bitet, így a bit0 biztosan 0 lesz, de a bit4 lehet akár 1 is. például 9 nél 0x12 lesz és nincs ennyi RETLW ha PCL hez adunk 0x12 t. Ilyenkor mi törénik ? Rosszul fogom fel ? Kössz
A PIC18 utasítások 16 bitesek, nemde? Ezért kell egy bittel balra tolni (azaz kettővel megszorozni) a 4 bites számot. 16 db. RETLW pont elég...
Uhhh kössz, erre nem gondoltam, hogy 2vel emelkedően kell itt.
PIC portlábak felprogramozásának összefüggései (pl. 16F153xx)A korszerű PIC-ekből én a a PIC16F1xxxx - Enhanced - család tagjait használom (ált. 153xx ill 183xx architektúrájúakat), s ezek többségében a ki/bemeneti lábakat számos módon be lehet állítani. A leírásokból azonban nem derül ki egyértelműen, hogy milyen kombinációk valósak, sőt az is kérdéses, hogy a PPS funkciók használata esetén azok mennyire illeszkednek ezen felprogramozható üzemmódokhoz?Tudomásom szerint a beállíthatóságok - némi korlátozásokkal - az alábbiak: ANSELx, TRISx, LATx, WPUx, ODCONx, SLRCONx, INLVLx ill. interrupt bemenetként az IOCxP, IOCxN. Az ANSEL még tiszta, az "mindent visz", kizárólag analóg lesz, ha arra állítjuk. Természetesen a LAT, ODCON csak kimenetként (TRIS 0) ill. a az INLVL csak bemenetként (TRIS 1) hatásos. Ám mi van a WPU-val bemenet esetén, vagy ha sima TTL kimenetről van szó? Akkor is rákapcsolódik egy felhúzó ellenállás? Vagy az SLRCON - ami mintha egy kondit csatlakoztatna a kimenetre - működik-e bemenet esetén (pláne van értelme ha SmithTriggerre állítjuk)? Szintén kérdéses, hogy ha egy lábat egy I/O kimenethez, vagy bemenethez rendelünk PPS-sel, akkor az a hozzárendelés hogyan szüntethető meg, ha csak sima PORT-ként akarjuk aztán használni? Ha pedig egy láb a belső I/O valamelyikéhez kapcsolódik PPS-sel, akkor (kimenetként) beállítható-e az ODCON, és/vagy a WPU? Idézet: Nem.„Ám mi van a WPU-val bemenet esetén, vagy ha sima TTL kimenetről van szó? Akkor is rákapcsolódik egy felhúzó ellenállás?” Idézet: Nem, csak kimenetre állított láb esetén van hatása.„Vagy az SLRCON - ami mintha egy kondit csatlakoztatna a kimenetre - működik-e bemenet esetén (pláne van értelme ha SmithTriggerre állítjuk)?” Idézet: Pl.„Szintén kérdéses, hogy ha egy lábat egy I/O kimenethez, vagy bemenethez rendelünk PPS-sel, akkor az a hozzárendelés hogyan szüntethető meg, ha csak sima PORT-ként akarjuk aztán használni?” RA0PPS=0; RB7PPS=0; Ilyenkor a kimenetet a megfelelő LAT regiszter vezérli. Ha perifériához rendlesz egy bemenetet (pl. Interrupt 0), akkor vagy a megszakítást tiltod le, vagy másik bemenetet választasz az adott perifériának. Ettől függetlenül digitális bemenet esetén a PORT regiszter olvasható és megfelelő értéket fog visszaadni. Idézet: Digitális kimenet esetén az ODCON és a WPU tetszőleges kombinációban használható. „Ha pedig egy láb a belső I/O valamelyikéhez kapcsolódik PPS-sel, akkor (kimenetként) beállítható-e az ODCON, és/vagy a WPU?”
Elnézést, összekevertem. A WPU-nak csak bemenet esetén van hatása, nyitott kollektoros kimenet esetén (ODCON) nincs, a felhúzást kívülről kell megoldani.
Köszi! Ezek mind, egytől egyik nagyon hasznosak voltak!
PIC32MZ2048EFM144 SOSC problémaSziasztok!Szeretném a segítségeteket kérni. A PIC SOSC külső generátorral van gondom. A generátor a PIC SOSCI lábára van kötve. Szeretném az RTCC forrásnak használni, de nem megy vele csak a belső LPRC-vel hajlandó menni, ami elég nagy pontatlanságat produkál. Kipróbáltam a Timer1 időzítő belső (PBCLK3 a forrás) rendesen működik. Ha a Timer1 a külső SOSC (T1CKI a forrás) nem működik, illetve nagyon hektikus és lassú. a PR1 = 100 ami kb. 3ms jelen, de a PIC kb 3-5 másodpercenként jelzi, hogy túlcsordul a TMR1. Megmértem a külső rezonátort oszcilloszkóppal, nincs vele gond 32,77 KHz négyszög jelet mérek. Nem megy vele sem a Timer1 sem pedig az RTCC. A PIC hibás lenne? Minden segítséget köszönök. BlackStar Timer1 beállítás: T1CONbits.TCS = 1; // SOSC T1CONbits.TCKPS = 0; // Timer1 prescale 1:1 TMR1 = 0; PR1 = 100; // kb. 3ms IFS0bits.T1IF = 0; IEC0bits.T1IE = 1; T1CONbits.TON = 1; PIC: PIC32MZ2048EFM144 (RevID:A1) Generátor: https://www.tme.eu/hu/details/osc32.768k-3.3_s5/smd-kvarcgeneratorok/yic/
Szia!
Nem ismerem a PIC-et, de az órajeled jelalakját, amplitúdóját is ellenőrizted DC helyesen?! A hozzászólás módosítva: Hé, 17:34
Szia!
Szerintem a jelalak rendben van.
Lehet, hogy én értem félre, de a másodlagos oszcillátor (SOSC) tulajdonképpen 32 768 Hz-es kristályt vár, de te aktív órajelgenerátort kötöttél oda. A T1CONbits.TCS=1 pedig nem SOSC-t jelent, hanem a T1CKI láb használatát.
szerk.: A konfigurációban engedélyezve van a másodlagos oszcillátor (FSOSCEN)? A hozzászólás módosítva: Kedd, 17:13
Szia!
Az errata szerint a SOSCO -ra kellene mennie a jelnek,csak úgy tudja fogadni.Sajna ezeknél az MZ-szériáknál elcseszték az oszcillátorokat . Talán még megoldás lehet,ha nem tudod áttenni a SOSCO-ra,hogy a SOSCI (73)(RPC13) pps-eled valamelyik timerre. Module: Secondary Oscillator A crystal oscillator cannot be used as the input to the Secondary Oscillator (SOSC) pins SOSCI and SOSCO. Silicon Work around Use an external clock source (32,768 Hz) applied to the SOSCO pin with the FSOSCEN bit (DEVCFG1<6>) set to ‘0’ (i.e., the SOSC is disabled through the Configuration Word) for a real-time clock base; otherwise, use the internal LPRC for non-precision requirements.
Köszönöm a segítséget mindenkinek.
Az RTCC lenne a fontos, hogy annak legyen a forrása a SOSC. A Timer1 csak a SOSC tesztelése miatt konfiguráltam. Érdekes ez a SOSC kezelése. Van 3db PIC32MZ2048EFM144 (külön nyák lapon) 1: PIC32MZ2048EFM144 Rev:B2 Az SOSCI (RC13) lábra egy 32.768 KHz generátor van kötve az SOSCO (RC14) lábra nincs kötve semmi. Tökéletesen megy a belső óra „RTCC” (RTCCONbits.RTCCLKSEL = 1, FSOSCEN = 1) a SOSC forrásról. A OSC 12MHz generátor A REV:B2 PIC32MZ2048EFM144 nincs gondom. 2: PIC32MZ2048EFM144 Rev:A1 A SOSC-nak egy 32,768 kristály van kötve a SOSCI SOSCO lábakra (nem generátor). Tökéletesen megy az RTCC belső óra. (Pedig elméletileg nem kellene a REV:A1 OSC probléma miatt) „The Secondary Oscillator (SOSC) does not support crystal operation. Rev A1, A3” Viszont ezen a nyákon primary SOC-nak szintén kristály van (12MHz) amivel nem megy csak a belső 8MHz FRC-vel. (Sajnos ezen a nyák lapon az USB-t nem tudom használni, belső FRC-ről nem megy) 3: PIC32MZ2048EFM144 Rev:A1 (ez a problémás nyák) Az SOSCI (RC13) lábra egy 32.768 KHz generátor van kötve az SOSCO (RC14) lábra nincs kötve semmi. Az belső óra RTCC nem megy csak (RTCCONbits.RTCCLKSEL = 0) a belső 32KHz oszcillátorról. (ami pontatlan) A primary OSC 12MHz generátor ez működik. Ezen a nyák lemezen nem tudom „rávenni” ![]() Az oszcilloszkóppal a SOSC generátor kimenetén nem tapasztaltam hibát Az RTCC lenne a fontos. AZ SOSCO-ra nem tudom tenni a generátort kimenetét mert az SOSCI-re van kötve. Esetleg ötlet? Végső megoldásként (I2C külső RTCC használnék). Idézet: Lehet, hogy igazábol arról van szó, hogy bizonytalan a dolog, így inkább hibásnak írták az A1 és A3 verziók esetén. Valószínűleg az egyik NYÁK-on szerencséd volt, a másikon nem.„elméletileg nem kellene a REV:A1 OSC probléma miatt” Ha az átkötés az SOSCO-ra nem megoldás, akkor külső RTCC marad (a működő Rev:A1 esetében is ezt lépném), mivel a RTCCLKSEL nem sok opciót kínál.
A szkópot azért érdemes lenne rátenni SOSCO lábra, mert ha azon már nincs meg a 32kHz-es jel, akkor esélyes, hogy az inverter nincs engedélyezve. Aztán lehet nyomozni, hogy ez SOSCEN nem meglétéből, vagy a chip hibájából ered-e. Érdemes az errata-t megnézni van-e erre vonatkozó bejegyzés.
|
Bejelentkezés
Hirdetés |