Nem lép, de ha tiltottam az összes megszakítást akkor is így viselkedett.

Nos, megoldódott. Kapott egy másik 4620-ast (ez is rev.0x07, vagyis B5) és működik. Visszatettem a régebbi 4620-ast és most ezzel is jó, pedig a kódhoz nem nyúltam csak a cpu tipusát állítottam tegnap 4520-ra. Lényegében vasárnaptól keddig szórakoztatott

Tedd vissza 4620-ra és próbáld meg újra! Lehet, hogy egy fordító hibát találtál! De lehet, hogy valami forrasztási hiba volt...

Visszatettem, tökéletesen működik. Forrasztási hiba nem nagyon lehetett, mert semmi máshoz nem nyúltam, csak a picet cserélgettem.

Foglalatban? Valami kontakt hiba is lehetett, vagy más elektromos zavar...

Heló Mindenkinek!

Programozással kapcsolatban szeretném kérni a segítségeteket. Egy időzítős áramkörön dolgozgatok, aminek egy DS1302 adná az RTC részét. Microchip C18-ban tudok C programokat írni, illetve ebben írtam már meg a programom teljes egészét. Az RTC-t nem tudtam működésre bírni saját kóddal, ezért a neten keresgetve találtam CCS-ben írt kódot, nagyon hasonlót ahhoz, amit Topi tett közzé egyik cikkében. És itt a gondom, hogy tudnám a kettőt összefésülni úgy, hogy ne kelljen átírnom a CCS kódot C18 fordítóra. (Egyébként már megpróbáltam, szerintem jó a kód, de mégsem tudom kezelni az RTC-t.)
Van erre valami fordítási lehetőség, hogy az RTC-t kezelő függvényállomány CCS-ben íródjon, a törzsprogram pedig C18-ban?
Válaszotokat köszönöm!

Sziasztok!
Szeretnék egy kis segitséget kérni.
C30-ban kezelnék T2 megszakitást.
Ebből kell meghivni egy viszonylag egyszerű függvényt.
A kód lefordul, viszont nem működik.
Össze-vissza ugrál, kontakt hiba szerűen. A függvény tartalma nem befojásolja az eredményt, üresen is ez a helyzet. Ha külső függvényt nem hivok akkor az interruptban lévő utasitások működnek.
Itt az isr cod:
void __attribute__((__interrupt__, no_auto_psv)) _T2Interrupt(void)
{

next_step();


led_2=!led_2;
IFS0bits.T2IF = 0; //Clear Timer2 interrupt flag
}
Auto_psv-vel is ugyanaz a hejzet.
Van valami tippetek hogy mi lehet a hiba?

Üdv kszabi

Szia!

Nézz szét ezen az oldalon.

Heló!

Köszönöm a segítséget, de mostanra rájöttem hol volt a gubanc a saját kódomban, és működésre bírtam.
Ettől függetlenül átnézem ezt a kódot is, hátha látok benne valami olyan megoldást, amit jobbnak találok a sajátomnál.

Üdv!

Sziasztok!

Egész ígéretesnek tűnik nekem ez a C18-as fordító...
Bele is vágnék az elsajátításába, de nem találok hozzá jó doksit. (olyan helló világtól kb) ((1000 éve már céztem egy keveset)

Tudna valaki küldeni leírást vagy linket? (magyar lenne a legjobb)

Előre is köszönöm.

A honlapomon található tananyag megfelel?
PICula projekt (PIC18F4520)
PICCOLO projekt (PIC18F14K50 és PIC18F4550)

Sziasztok!

Lenne egy óriási kérdésem! Szeretnék egy 24-es PIC-et és egy másik meghajtó áramkört használni kristály oszcillátorról, de a másik áramkörhöz 1 MHz órajel szükséges a PIC-et pedig szeretném 16 vagy 24 MHz-ről használni! Van valakinek erre valami egyszerű megoldása??? Melyik a praktikusabb, ha az 1 MHz-et szoroznám fel vagy ha a 16/24 MHz-et osztanám le??

Kérlek segítsetek!! Előre is köszi!!

Azon azért gondolkodjál el, hogy a C18 end-of-life termék, azaz deklaráltan nem lesz több verziója, és már az utódja (XC8) is megjelent. Ha még csak most ismerkednél meg vele, lehet, jobb ötlet lenne az aktuálisnak tekinthető, jövőbiztos utódját nézegetni.

Fényévekkel egyszerűbb a leosztás.
99%, hogy a PIC-ed valamelyik belső alkatrészével elő lehet állítani az egyik lábán egy leosztott 1MHz-es jelet (valamelyik timer lenne az első ötletem). Ennek persze az lesz az ára, hogy az adott alkatrészt a PIC-en belül erre el kell használnod, továbbá a kimenet elvesz egy lábat.
Ha ez gond, akkor még mindig használhatsz egy másik kvarcot az 1MHz-hez...

Köszönöm szépen, ez tökéletes lesz.

köszönöm ezt a tippet is.

Hali!

Nem lene ez a probléma, de az a baj, hogy a PIC-nek kellene a nagyobb freki, és a másik áramkörnek a kisebb 1 MHz. Szóval arra gondoltam, hogy a PIC kapna egy 16/24 MHz-es kristályt és azt kéne valami külső áramkörrel leosztani. Ötlet??

Olvasd el mégegyszer amit _VL_ írt.

Kössz!! Igazad van egy mondat kimaradt az olvasásából

Sziasztok!
Még a múltkor belefutottam valamibe PIC24 programozása közben, aztán annyiban is maradt a dolog, viszont most megint eszembe jutott.
Egy kis pointer-aritmetika.
Miért van az, hogy a következő kódrészlet hibátlanul fut PC-n, viszont se 24-esen se 32-esen nem akar. Mindkét esetben a trap-ben landol a program.

Először arra gondotlam, hogy a memória alapegységén túlnyúlik a dolog, de a *p16 os indirekció se tetszik neki.
Van ötletetek?

Az lehet a probléma, hogy páratlan című bájtot akarsz megcímezni olyan mutatókkal amelyek valószínűleg csak páros címre mutathatnak.

A

se működik, pedig pont meglenne a 2 bájtnyi hely, ahova le tudja rakni.

Meg kell nézni, hogy ez mire fordul le. Nyilván nem viccből jön a trap...

Ellenőrizd hogy milyen hibakizárás történik ilyenkor! (Én pl. többnyire a 16-bites operandusz páratlan címre történő hivatkozását szoktam elkövetni. Ilyenkor anyázok rendesen, de a végén mindig kiderül hogy én vagyok a hülye.)
Biztosítsd, hogy a szó nagyságú adatok mindig páros címre kerüljenek (.align 2), ill. a kiszámolt mutatók és indexek mindig párosak legyenek! (Arra is figyelj hogy a RAM-ban az adattárolás "little endian" rendben történik, azaz a kisebb memóriacímre magy a kisebb helyiértékű byte!)

Hello!

Adott ez a 24F16KL402 PIC-em. Egy analóg szervót szeretnék a CCP2 modullal vezérelni. Abba a problémába futottam, hogy magát a PIC-et a belső oszcillátorról PLL-el 32Mhz-en működtetem és a CCP modulba ennek a fele megy be. Ezt leosztva még a 16os előosztóval mire túlcsordul 3900Khz körüli frekit kapok a kimeneten, de nekem olyan 30-60Hz kellene ha jól informálódtam a szervó impulzus frissítéséhez. Lehetőség van az adatlap szerint a TMR3 kiválasztására ami 16bites, de ezzel sem jutottam semmire. A datasheet szerint ez csak úgy használható CCP/ECCP modulhoz időalapnak, ha a külső másodlagos oszcillátort használom ami értelmezésem szerint max 32Khz lehet vagy a belső 32Khz használható vagy a T3CK bemenet aszinkronban. Talán ez utóbbi lehetne még megoldás? Viszont akkor kell építenem egy külső jelforrást párszáz khz-re. Ha jól értelmeztem ez a TMR3 csak túlcsordulásnál jelez a CCP modulnak. Nem tudom befolyásolni hogy pl csak a felét számolja le? Töltsek bele előre egy értéket? Vagy kezeljem le szoftveresen a szervót? Még annyi, hogy a TMR2 és a TMR4 8 bitesek amiket lehetne még használni csak belső Fosc/2-ről mennek. Ha valakinek lenne jó ötlete, tudna segíteni az nagyon jól jönne Végső soron használom kisebb órajelen a pic-et vagy csinálok valami jelgenerátort a T3CK-ra. Mondjuk érdekes, hogy lehet referencia órajelet kitenni pont arra a lábra, de nem működött úgy.

Köszönöm előre is!
Tamás

Pontosan az amit mondtál, hogy páratlan címet nem szereti. A kérdés inkább az, hogy miért? És más rendszreken miért működik? Lehet hogy a "free" módnál valami korlátozás?
Mindenesetre a szabály tényleg az, hogy 16 bites-t csak kettővel, 32-est csak 4-el osztható címre tud letárolni.
Ez abból is látszik, hogy ha felveszek egy ilyen struktúra tömbböt,

Akkor egy elem 4 bájtot foglal. Ami azért mégiscsak 75% hatásfok...

Muszáj ezt a nyomorék típust használni? Ennek elég hülyék a timerei?

A szervó vezérlést többnyire nem hardveresen csinálják, hanem félig hardveresen. Egy timerrel akér több csatorna is vezérlhető, csak az ismétlődésű időt (ami általában 20 ms körüli) szeletekre osztják, s egy-egy időszeletben egy-egy szervócsatona jelét elő lehet állítani.

Az időzítés trükkje az, hogy annyi óraütéssel kell a túlcsordulás előttre állítani a számláló értékét, amennyi idő múlva valamelyik kimenetet kapcsolni kell. Végeredményben tehát nem kell sem PWM, sem Output Compare modul, csak egy szimpla Timer megszakítás.

Nem a fordítónál és nem a free változatnál van korlátozás, hanem a PIC felépítésében, működésében.

A szó vagy duplaszó szélességű adatmozgató utasítások esetén az adatoknak szó igazítású (word-aligned) címeken kell kezdődnie, azaz a legalsó címbit nulla kell, hogy legyen. Erre a dsPIC30F/33F Programmer?s
Reference Manual (DS31037B)-nak a "4.5 Word Move Operations" című alfejezete hívja fel a figyelmet.

Ja, a dsPIC miatt ne izgasd magad, a PIC24F és PIC24H típusokra is csak ez a kézikönyv van.

Azért, mert ehhez (amit szeretnél) az egy darab memóriaműveletből kettőt kell csinálnia a CPU-nak. Beláthatod, hogy ez baromira elbonyolítja egy átlagos RISC CPU logikáját (alapesetben ott az "egy utasítás: nulla vagy egy memóriaolvasás az elején, nulla vagy egy memóriaírás a végén" a logika), mivel az átlagos RISC CPU egy nagyon egyszerű valami, és relatíve sokba kerül ez az extra buszlogika. Egy átlagos CISC CPU-nál (pl. x86) már egyáltalán nem aránytalan a dolog, mivel ott már amúgy is rettentő sok minden van a CPU-ba belegyömöszölve. További paraméter, hogy x86-nál amúgy is teljesen kiszámíthatatlan, hogy hány CPU ciklus alatt fut le egy utasítás, míg a RISC alapvetően úgy van tervezve, hogy minden ciklusban lépünk tovább, amit meg kéne akasztani minden ilyen duplázott memória hozzáférésnél.

Ezért van az, hogy a RISC CPU-k kb. 98%-a nem tudja a fent kifogásolt műveletet, cserébe generál neked egy exception-t. Aztán sw-ből emulálhatod a műveletet, persze kb. 100-szor lassabb leszel így...

Mármint az a kérdés hogy miért nem szereti, vagy az hogy miért akar egyáltalán páratlan címhez hozzáférni?

A legtöbb 16-bites (ill. 32-bites) rendszernél ez a helyzet, mert a proci, a címdekóder és a RAM ilyen felépítésű. Az adatbusz tehát 16-bites, és a címbusz egy memóriacikluson belül csak egy címet jelölhet ki a címtartományon belül, így egy szó elérése 1 utasításciklust vesz igénybe. (A címek byte-osával vannak kiosztva, az adatbusz viszont 16-bites.) Ha páratlan címről kellene 16-bites (szó méretű) adatot olvasni, ahhoz először a páratlan címről kellene beolvasni a szó első byte-ját, majd a következő (páros) címről a második byte-ját. Ez viszont két utasításciklust venne igénybe, ill. a hardvert bonyolítaná, így aztán ez a mód általában nem megengedett. (Példaképpen: a 16/32-bites Motorola MC68000 procinál is ilyen megkötés van, viszont a nagytestvérénél - a 32-bites MC68020-nál - már páratlan címről is lehet szavas (16 bit) ill. hosszúszavas (32 bit) adatot olvasni (ill. írni), viszont ezesetben a memóriaciklus duplahosszú ideig tart a fenti ok miatt.)

Egyébként 16-bites rendszernél nincs olyan megkötés a 32-bites adatokra, hogy csak 4-gyel osztható címeken tárolhatók. (Az csak 32-bites prociknál jöhetne szóba.) Tehát a 32-bites adatoknak is 2-vel osztható címen kell lenniük.
Továbbá: 8-bites rendszereknél sincs megkötés a címekre vonatkozóan, mert ott a 16-bites adatot amúgyis mindig byte-osan, 2 hozzáféréssel kell kiolvasni.
Valamint: ha 16-bites rendszeren a 16-bites adatokat byte-onként kezeled, akkor sincs ez a megkötés.