Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Idézet: „inkább R1 értékével van probláma” Igen, én is erre gondoltam, mikor a kicsi módosítást említettem. A külső feszültségfüggő resetet már meg sem említettem, mert az még is csak célirányos feladat, programozáskor illik leválasztani, pl. egy jumperrel. De az MCLR alap bekötésénél ne legyen már problémát okozó rajz. Mi is mindig az adatlapra hivatkozunk, ne kelljen már külön magyarázkodni az ilyen alap dolgoknál. Volt is ilyen korábban, hogy nehéz volt meggyőzni a kezdő kérdezőt, hogy az adatlappal ellentétben ne tegyen oda diódát, mert akkor talán fel tud épülni a kicsi áramra méretezett Vpp az égetőjében! 
Szerintem valamit félreértettél, vagy inkább rossz szempontból kiindulva ítéltél meg!
A 3-3. ábra a külső reset áramkör szükségességéről szól, amire bizonyos speciális feltételek mellett szükség lehet. Ezt - mármint a biztonságos (újra)indulást - egy gyakorlati alkalmazásnál nem lehet alárendelni a "kényelmes" újraprogramozás szempontjainak. Egy kenyérsütő vagy hőmérős óra, esetében pl. nem túl gyakran kell újraprogramozni. Főleg, ha OTP... Nem csak az ábrán szereplő dióda, hanem sok más egyéb is csatlakozhat az MCLR lábra (IC-s külső reset áramkör, vagy más logikai áramkörök, ha logikai bemenetként használjuk az MCLR lábat - én is csináltam már ilyet!) amelyek akadályai lehetnek a magasfeszültségű programozásnak. Gondot nem látok, mert az ICSP programozásól szólva mindig elmondják, hogy minden külső áramkört megfelelően le kell választani. Ha másképp nem megy, akkor jumperrel. Abban igazad van, hogy kezdő vagy hebehurgya amatőrök átsiklanak efölött (én is jártam már így, figyelmetlenségből!), de ha ezt sem tanulják meg, akkor a bonyolultabb dolgokat hogyan fogják?
Igen, valóban átsiklottam e fölött, igazad van a dologban!
Hello!
Egy gyors kérdés!?! Az USART foglalkozik a Start és Stop bitekkel?! Ha igen, akkor a Manchester kódolást hogyan fogja értelmezni?! Üdv. Idézet: „Egy gyors kérdés!?! Az USART foglalkozik a Start és Stop bitekkel?!” Igen Idézet: „Ha igen, akkor a Manchester kódolást hogyan fogja értelmezni?!” USART == Universal Synchron/Asynchron Receiver Transmitter ...azaz nem Ethernet... Idézet: „Ha igen, akkor a Manchester kódolást hogyan fogja értelmezni?!” Átalakítja Overrun meg Framing Errorokká. Manchester dekódoláshoz az USART direktben nem jó. Más módszert kell keresni, pl. CCP modullal vagy timerrel+külső megszakítással lehet mérni az impulzusok szélességét. De ha a neten keresgélsz, akkor lehet találni mintakódokat. Idézet: „akkor a Manchester kódolást hogyan fogja értelmezni” Mi ezzel a probléma? Te bájtokat raksz a TXREG és bájtokat veszel ki a RCREG regiszterekből. Mindegy, hogy milyen kódolást használsz, hogy egy bájtból kettőt csinálsz és úgy küldöd, ezt nem befojásolja az USART.
Nah, erre nem is gondoltam, hogy így 2 bájtot küldök! :S
Akkor viszont maga az USART teszi rá a Start és Stop bit-et, így már értem! Vagyis, 8bit-es adatnál, a Manchester kódot átalakítja 16Bit-re, és ezt 2 "csomag"-ban küldi el! Köszi, most már értem! 
Nem az USART alakítja az egy bájtot kettőre ( vagy a kettőt egyre ), hanem te a kódoló programoddal, amit külön megírsz!
Idézet: „Akkor viszont maga az USART teszi rá a Start és Stop bit-et, így már értem! Vagyis, 8bit-es adatnál, a Manchester kódot átalakítja 16Bit-re, és ezt 2 "csomag"-ban küldi el!” Meg egyszer: Az USART az egy egyszeru soros kommunikaciot megvalosito modul! Nincs benne Manchester kodolas! A byte-odat sem figja szetszedni neked word-re... Ha mindenaron Manchesterben akarod elkodolni akkor vagy teljesen szoftveresen megvalositod vagy lehet valamit tudsz ugyeskedni synchron soros modban, bar ez utobbi erosen ketseges. Miert ragaszkodsz a Manchesterhez vagy mihez kell? Idézet: „Vagyis, 8bit-es adatnál, a Manchester kódot átalakítja 16Bit-re” Nem alakít semmit sehová! Elérak egy start bitet, mögé rak 1 vagy 2 stop bitet, az adatbájtot viszont úgy küldi ki, ahogy van. Ha mind a 8 bit nulla, akkor nyolc bitidőn keresztül nullán marad...
Üdvözlök mindenkit az oldalon.Lenne egy nagy kérdésem, amiben segítségre szorulok PIC ügyben.Sajna e téren még nincsen nagy gyakorlatom.Építettem egy LCD- oszcilloszkópot egy PIC16F877-el.A ketyere szépen működik is ,de sajna a bekapcsolásnál nem mindig indul be.Ki- be kell kapcsolgatni ütemesen, és pár indítás után elindul.Próbáltam a reset lábat is aktív szintre tenni hosszabb ideig, de semmi változás.Átalakítottam a tápellátását is, hogy elemről is működjön, és így sokkal könnyebben elindul.Ha valakinek lenne esetleg ötlete azt köszönettel fogadnám.
Kapcs rajz? Anelkul nagyon nehez barmit is mondani...
Innen töltöttem le. Bővebben: Link Itt a rajz , és a progi a PIC-be is.
Szia!
Az a 10µF nem sok az MCLR lábon? Én megnézném 100 nF-dal. Üdv. P istván
Probaldd dmeg 20p helyett 15p-vel a kristaly korul. 100nF meg szerintem mindket Vdd agra kulon kellene a labakhoz minel kozelebb. Amit P_istvan mondott is jogos lehet. Meg kellene nezni a tapot mi tortenik bekapcsolaskor, lehet megrantja valami (mondjuk a kondi mikozben feltoltodik)
Elég merész dolog 24 MHz-en hajtani, csoda, hogy megy egyáltalán! Az oszcillátor beindulását jó volna ellenőrizni.
Ezeknek a 16-oknak szokott lenni 18-as párjuk, ráadásul a program corrása c talán egyszerű lehet átírni. A 18-asokat már simán lehet hajtani 24MHz-vel nem?
Egy érdekesség: Pl. ITT van egy led matrix kijelző meghajtó, és a specifikációk között van ez a sor: (6) Controlling chip PIC16F57 with a 25MHz oscillator.
Én nem azt mondtam hogy nem lehet, hiszen elindul csak kicsit rugdosni kell, csak arra utaltam, hogy a 16-osnak vannak lábkompatibilis 18-as megoldásai is, amik már simán bírják a 25MHz-t, és mivel C jó eséllyel minimális módosítással menne a program.
Szia!
Lehet, hogy a megadottnál nagyobb frekvenciájú órajelet a CMOS integrált áramkörök elviselik, de két apró probléma merül fel: - A tok disszipációja u*u*f -fel arányos, tehát 25MHz-n 1.25 szöröse a megengedett órajellel működőének. 20 MHz felett a tápfeszültséget csökkentik. - A nagyobb belső hőmérséklet és töltésáramlási sebesség nagyobb belső anyagáramláshoz vezet, ami a chip struktúráját rontja. A túlórajelezett áramkörök rövidebb élettartamúak.... Szia Idézet: „A túlórajelezett áramkörök rövidebb élettartamúak...” Azért nem olyan vészes itt a helyzet. Valóban nagyobb a melegedés, de eleve nem olyan mértékű, hogy ez a kis plusz gondot okozzon. Szerintem nem lehet olyan magas órajelen járatni, aminek hatására emberi idő alatt tönkremegy a chip, mert más paraméterek lekorlátozzák a sebességet.
Nagyon szépen köszönöm az értékes információt mindenkinek.Sorra végig fogom nézni az összes lehetőséget.Megvallom igazán attól féltem, hogy a programmal van a gond.Amint lesz bármilyen eredményem beszámolok róla.
Sziasztok!
Szeretnék segítséget kérni az alábbi témában, amit már rég tettem fel! Hozzászólás! Annyi változás van, hogy az első számjegy, jól működik, megfelelő oldalról nézve a jobb oldali, a többi mind 8-as marad, és nem változik meg  Köszönöm előre is!  Üdv.
Nos tettem 2db 15p kondit a kvarc-mellé, kicseréltem az MCLR lábon a 10mikrósat 100n-ra, és tettem mindkét Vdd-re 100nf-ot.Ezeket közvetlenül a PIC lábára.Nagyságrandelket javult a helyzet, azonban még is előfordul, hogy nem indul.Sajna a szkópom 10Mhz-es, nem látom vele az órajelet.Esetleg van még ötlet??
Új fejezettel gyarapodott a PIC 18 mikrovezérlők programozásával foglalkozó PICCOLO projekt (Ismerkedés a PIC18 mikrovezérlőkkel)!
A legújabb fejezet: Kiterjesztett pontosságú műveletek A fejezet tartalma: * Több-bájtos változók inicializálása * Több-bájtos bitenkénti logikai műveletek * 16 bites összeadás és kivonás * 32 bites összeadás és kivonás * 16/32 bites inkrementálás és dekrementálás * 16/32 bites logikai eltolás * Kiterjesztett pontosságú feltételvizsgálatok * Előjeles egész számok ábrázolása * Túlcsordulás a kettes komplemens ábrázolású aritmetikában * Műveletek előjeles változókkal * Aritmetikai eltolás jobbra * Előjeles feltételvizsgálat * Előjel kiterjesztése Bővebben: http://esca.atomki.hu/PIC18
szép munka, csak gratulálni tudok hozzá.
Hasonloan szinvonalas es szep munka mint a pickwik. Minden elismeresem!
Egy apro elirast talaltam most nagy hirtelenjeben: A dekrementalasnal k++ -t irsz, nyilvan csak a copy-paste eredmenye.
Köszönöm az észrevételt, javítottam. A hasonlóság pedig nem véletlen: hiszen a PICkwik fejezeteket dolgozom át.
Talán butaságnak tűnik a visszalépés (PIC24 után PIC18 tananyagot fordítani), de rá kellett döbbennem, hogy PIC18-hoz nagyon kevés olyan könyv vagy leírás található, ami minden szempontból kielégítőnek mondható. Bob Reese kitűnő könyve (és a hozzá kapcsolódó, weben közzétett tananyag) tehát megérdemli a figyelmet.
Szia!
Nagyon szépen összeállított anyag. Ilyen rendezetten leírt magyar forrást még nem olvastam másutt. Az assembly résznél az utasításoknál le kellene írni, hogy melyik flag-eket állítják. Egyrész új flag-ek vannak (Overflow, Negative), másrészt a 16F -hez képest van némi eltésés az utasítások között. Pl. a 18F az incf/decf utasítás végrehajtása után állítja a C flag-et. Hasonlóan rrf/rlf nincs, a rrncf, rrcf, rlncf, rlcf viszont állítja a Z-t. Szerintem kimaradt branch utasítás, a relatív ugrás. Ezek talán a következő részbe illenének: Eltérés még az utasítások helyfoglalásának számítása. Főleg a kiszámított ugrásnál jön elő: a kívánt sorszám kétszeresét kell keírni, a PCL írásánál az lsb helyett 0-t vesz figyelembe. A pclatu, pclath feltölthető a PLC olvasásával. Szia |
Bejelentkezés
Hirdetés |
