Fórum témák

» Több friss téma
Fórum » PIC - Miértek, hogyanok haladóknak
Lapozás: OK   571 / 1319
(#) watt válasza Hp41C hozzászólására (») Szept 10, 2009 /
 
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!
(#) icserny válasza watt hozzászólására (») Szept 10, 2009 /
 
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?
(#) watt válasza icserny hozzászólására (») Szept 10, 2009 /
 
Igen, valóban átsiklottam e fölött, igazad van a dologban!
(#) robing16 hozzászólása Szept 10, 2009 /
 
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.
(#) trudnai válasza robing16 hozzászólására (») Szept 10, 2009 /
 
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...
(#) potyo válasza robing16 hozzászólására (») Szept 10, 2009 /
 
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.
(#) MPi-c válasza robing16 hozzászólására (») Szept 10, 2009 /
 
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.
(#) robing16 válasza MPi-c hozzászólására (») Szept 10, 2009 /
 
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!
(#) MPi-c válasza robing16 hozzászólására (») Szept 10, 2009 /
 
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!
(#) trudnai válasza robing16 hozzászólására (») Szept 10, 2009 /
 
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?
(#) icserny válasza robing16 hozzászólására (») Szept 10, 2009 /
 
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...
(#) Beachway hozzászólása Szept 10, 2009 /
 
Ü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.
(#) trudnai válasza Beachway hozzászólására (») Szept 10, 2009 /
 
Kapcs rajz? Anelkul nagyon nehez barmit is mondani...
(#) Beachway válasza trudnai hozzászólására (») Szept 10, 2009 /
 
Innen töltöttem le. Bővebben: Link Itt a rajz , és a progi a PIC-be is.
(#) p_istvan válasza Beachway hozzászólására (») Szept 10, 2009 /
 
Szia!

Az a 10µF nem sok az MCLR lábon?
Én megnézném 100 nF-dal.

Üdv. P istván
(#) trudnai válasza Beachway hozzászólására (») Szept 10, 2009 /
 
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)
(#) icserny válasza Beachway hozzászólására (») Szept 11, 2009 /
 
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.
(#) gulasoft válasza icserny hozzászólására (») Szept 11, 2009 /
 
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?
(#) mammut válasza gulasoft hozzászólására (») Szept 11, 2009 /
 
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.

(#) gulasoft válasza mammut hozzászólására (») Szept 11, 2009 /
 
É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.
(#) Hp41C válasza mammut hozzászólására (») Szept 11, 2009 /
 
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
(#) potyo válasza Hp41C hozzászólására (») Szept 11, 2009 /
 
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.
(#) Beachway hozzászólása Szept 11, 2009 /
 
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.
(#) robing16 hozzászólása Szept 11, 2009 /
 
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.
(#) Beachway hozzászólása Szept 11, 2009 /
 
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??
(#) icserny hozzászólása Szept 11, 2009 /
 
Ú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
(#) gulasoft válasza icserny hozzászólására (») Szept 12, 2009 /
 
szép munka, csak gratulálni tudok hozzá.
(#) trudnai válasza icserny hozzászólására (») Szept 12, 2009 /
 
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.
(#) icserny válasza trudnai hozzászólására (») Szept 12, 2009 /
 
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.

(#) Hp41C válasza icserny hozzászólására (») Szept 12, 2009 /
 
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
Következő: »»   571 / 1319
Bejelentkezés

Belépés

Hirdetés
XDT.hu
Az oldalon sütiket használunk a helyes működéshez. Bővebb információt az adatvédelmi szabályzatban olvashatsz. Megértettem