Rendben, köszönöm, ez így megy. A következő problémám az, hogy a CCP2 modult szeretném használni. Ennek a kimenete az RC1. Bekapcsoltam mind az 5 CCP modult, de csak ennek nem látszik a kimenete. Ezért gyanakodtam arra, hogy gond van a porttal. A kód, ami a 4 további CCP modullal működik:



A PWM-hez szükséges Timer2 be van állítva.

Ez egy közönséges földi halandónak semmit sem mond. Hívják akár k8084-nek vagy MZ/X-nek. Amióta kapcsolási rajzot kitalálták, azóta az az összehasonlítás elsődleges forrása. Mi a különbség a két áramkör között? (hogy állunk az MCLR felhúzással, s 628 vagy 628A-val kísérletezel?) Hibakeresés (a jövőben) ezek mentén végezhető.

16f628A

Sziasztok. Flowcode-ban programozok pic-eket. A flowcode-ban nincsen véletlen számgenerátor, de van rá lehetőség C kód beillesztésére. Ebben szeretnék segítséget kérni. Tehát valamilyen számgenerátor kellene C nyelven.

( Ennyit a gyári k8084-es égetőről - K8048 rendelési számon )

Köszi. Már vagy háromszor átnéztem a súgót de nem találtam semmit.

Aha. Azt Ideiglenes mar kideritette neked, hogy egy Velleman programozo/proba paneled van. Ezek szerint ezen a proba panelen mukodik az amit megirtal.

Namost van egy masik aramkorod, amirol semmit sem mondtal. Ennek kellene mellekelned a kapcsolasi rajzat, hozza a programot (mert, ha kerdezel, akkor ugy illik, hogy a segito embereknek minel kevesebbet kelljen utana nezniuk mit hol talalnak meg, kulonben elmegy a kedvuk a segitestol...). Szoval kapcs rajz (nem panel terv!) es forras kod kellene, es egy preciz leiras mit varsz az aramkortol ill. programtol, es ehelyett mit csinal...

Helló. Ne haragudj de, mindent elküldtem lejjebb olvasva ott van a kapcsolási rajz is.

Bocs. Hogy elirtam az égető számát.

Sziasztok!
Nekem egy olyan progit kéne pic-re írnom, ami tulajdonképpen egy óra, mondjuk 0-99másodpercig számol, és BCD-ben írja ki az eredményt. (pickit2-n 8db leden) Tud ebben valaki segíteni. Én nem nagyon vágom ezt a témát.
....@....hu

Mail címet töröltem.

1. Ne írd ki nyerseny semmilyen fórumra soha, csak ha mazochista módon szereted a spam-eket!

2. Azért fórum, hogy ne e-mailben kérd a választ, mert az illetlenség.

OK!

Sziasztok!
Senkinek nincs ötlete a korábban feltett (#906352) alatti PMP buszos kérdésemmel kapcsolatosan?

A 'Kapcsolasok' alatt a 'PIC' -et kivalasztva beirtam, hogy ora, es ezek jottek ki eredmenyul...

Sziasztok!
Két nagyobb kérdéssel fordulok hozzátok.

1.) a tökéletesen működő lcd vezérlő forráskódom áttettem, 16f887 ről 18f4550-re egy utasítást kicseréltem, az rlf-et rlcf-re, ezen kívül még az analóg beállítást elvégeztem, mást nem nagyon vettem észre hogy különböznie kéne a 16f-es asm kódtól. Sajnos a program, nem lép ki egy rutinból, tehát adott a kilépési feltétel, és egy szubrutinon belül 16bites matematikai műveleteket végez, összeadás kivonás, 2es komplemens képzés. Ami 16f en tökéletesen működött, az egész itt 18f-en már nem. Olyan mintha a matematikai műveletekkel lenne baj, de átnéztem az adatlapokat és a c,z egy helyen van a status -regben, az összeadó kivonó művelet nem változott. Nem értem, kérlek segítsetek!

2.) Igazából kényelmességi okokból kezdtem el átalakítani a programomat a 18as szériára, mert elérkeztem az első program memória lap , határához, és megrekedtem, sőt ugye a pc ugrások sem működnek tökéletesen simán 256 sor ugrás után. Ennek mi a kiküszöbölési megoldása? Szívesen maradnék a 16 os szériánál!

Válaszotokat előre is köszönöm!

Szia!
- A18F -en néhány utasítás más flag-eket is állít, mint a 16F -en (incf állítja a C-t is, rlcf, rlncf, rrcf, rrncf a Z-t is). Nézd meg az adatlap Instruction set summary fejezetét.
- A18F -en van addwfc, subwfb, subfwb a 8 bitnél hoszzabb számok kezelésének könnyítésére.
- A 18F a kiszámított ugrásoknál byte -os címzést használ, az utasítások szavasak, az indexet duplázni kell. A goto, call viszont 4 byte, az ilyen utasításokból felépített kiszámított ugrásnál az indexet négyszerezni kell.
- A szavas utasítás és a byte-os memória címzés miatt a 256 byte-os határ hamarabb betelik, mint a 16F-en. Kivédésére több megoldás is van:
-- Fordítás alatti ellenőrzés: Ha egy kiszámított ugrás táblázat kezdetén és végén elhelyezett címkék felső bitjei nem egyeznek meg, hibát lehet okozni.
-- Eleve feltételezni, hogy a táblázat átlóg a 256-os határon, a PCLATU, PCLATH regisztereket módosítani.
-- Ötlet: A PLC olvasása feltölti a PCLATU, PCLATH regisztereket.

[OFF]Szlovakiaban is lehetett erezni a rengest tobb helyen

Gyors válaszod köszönöm!
- a 16F es szoftvert úgy alakítottam ki , hogy ne legyen gond a rontott z illetve c. elviekben ez nem nagyon lehet a baja. e nélkül is ki kéne lépnie a szubrutinból, de mindjárt csinálok egy szimulációt hogy tuti jól ad e össze meg von-e ki, mert kivételes esetben ha elrontja a -1 hozzáadását vagy a +1 hozzáadását, akkor nem lép csak ki.
- ami egyszer már bevált azt nem feltétlenül írnám át aznap mikor elkezdtem megismerni a 18F et
- ezt úgy értsem, hogy egy goto $+.4 re ugorna igazából a következő sorra?

-- pcl olvasása jónak tűnik, na de ez érvényes a 16F-re is ?

szerk. úgy vettem észre hogy a gotonál duplázás van. nem?

köszönöm a segítséget, eljutottam oda ahol eddig a 16F el voltam most már jó. az indexelt ugrásokkal volt csak a gond, mert csináltam egy 16-16 bites összehasonlító makrót és abban van csak másutt törekedtem az átláthatóság miatt címkét használni. goto $+.10 ez 4 sort ugrik előre. tehát az önmaga sora(2) +2* sordb szám , viszont azt nem értem hogy, a goto $-.10 miért nem működik.

PIC18-nál a memória bájtonként címezhető, az utasítások viszont 2 vagy 4 bájtosak ezért a $+n és hasonlókról sürgősen le kell szokni! Használj címkéket!

A GOTO fölösleges idő/hely pazarlás, PIC18-nál célszerűbb a bra, bc, bnc, bz, bnz, bn, bnn, bov, bnov elágaztató utasításokat használni.

PIC18F4550-hez nézegesd a honlapomon található PICCOLO projekt c. tananyagot!

Ezeket a kérdéseket a szimulátor olyan jól meg tudja válaszolni!

Makroban is lehet cimkeket alkalmazni, cska meg kell neki mondani, hogy a cimke 'lokalis'. Nem jok ezek a dollaros dolgok... mar csak azert sem, mert nem 'sort' ugrik (2*sorszam), hanem memoria cimeket. Te ugye azt feltetelezed, hogy 1 sor 1 szo, azonban vannak 2 szavas utasitasok is!

Amugy ha csak a laphatar miatt valtottal 18F-re, akkor meg rosszabbul jartal, mert ott max csak 128 elemet tarolhatsz el egyetlen lapon szamben a 16F 256-javal. Tessek szepen azt a 16 bites PC szamitast megcsinalni tisztessegesen

Szia!

- 16F -n a PCL olvasása nem tölti fel a PCLATH -t.

- Táblázat elhelyezkedésének ellenőrzése absolute kódnál pl:

Azt hiszem, eléggé elítélhető módon, de én a 16F-eknél is használom mostanában ezeket az elágazásokat (bc, bnc, bz, bnz-t biztosan). Igaz, hogy ebben az esetben ezek nem utasítások, hanem makrók, de úgyis arra fordulnak, amit magától is írna az ember, viszont - számomra - a kód jobban értelmezhető. Arról nem is beszélve, hogy ha véletlenül kihíznám a 16F-et a firmware-rel, akkor 18F-re portoláskor ezekhez már nem is kell nyúlni.

A $-os goto-kat mindenhol kerülöm. Makróba is érdemes rendes címkét tenni, azt lehet lokálisnak definiálni (vagy eleve úgy jön létre?), így a makrót többször felhasználva sem lesz címkeújradefiniálási hiba. A címkézett makrók szintén jobban portolhatók, mint a $-os ugrásokat tartalmazók.

Nem sajnos, arrol neked kell gondoskodnod, hogy azok a cimkek lokaliskent legyenek definialva.

A legnagyobb eltérést én is a táblakezelésben látom. A 18F táblakezelés fejlettebb, nem érdemes a 16F-es metódust használni rajta szerintem...

Talán az összes család (a 32 biteseket leszámítva) legjobb program memória kihasználhatóságával a 18 -as család rendelkezik. Egy program szóban 2 byte tárolható, a táblázat folytonos. A 24F, 30F, 33F családban az utasítás 3 byte, de a memóriában kiegészül egy negyedikkel - a táblázat kezelésében egy lyukat okozva...

Köszönöm mindenkinek a válaszát!

Természetesen LOCAL-lal deklarálom a makróban a helyi címkéket, a nagyon zűrös helyeken volt goto $ de kijavítom igazából nem is a táblázatokkal lenne a gondom, (amit még kifogok rajta javítani, hogy ne legyen ekkora a program memória, az egyik marót átalakítom szubrutinra, mert azt a makrót meghívom vagy 70 szer és maga a makró van vagy 35 sor.. későn jöttem rá hogy ez most 70szer bele fog kerülni a forráskódba ) hanem írom írom a programomat (16F-en) és elérkezek a 07FF es hexa címen lévő program memóriához, és amikor átlépem, akkor el sem indul a programom. Ez itt minden problémám gyökere

Szia!

A 16F memóriájában un. page -ek vannak. A goto / call utasítások a cél cím alsó 11 bitjét tárolják. A végrehajtáskor a felsőbb biteket a PCLATH regiszterből 3. és 4. bitjéből veszi.

Több lapon elhelyezkedő program esetén az alábbiakat kell megtenni:
- Megszakítási rutin: az első ugrás előtt a PCLATH mentése, a megszakítási rutin page -nek megfelelő beállítása, a kilépés előtt a mentett érték visszaállítása.
- Page -ok közötti átlépés: A PCLATH beállítása a cél page -nek megfelelően, goto / call.
- Rutinból való visszatérés után: A return nem állítja a PCLATH -t, a visszatérés után arra a page -re állítani, amin a program folytatódik.

A szimulátorban jól nyomonkövethető...

A legegyszerűbb, ha a táblázatok kerülnek át másik lapra: A PCLATH -t a 256 -os határ miatt eleve kellett állítani. A visszatérés után kell csak módosítani a PCLATH -t.

A hosszú makrókat tényleg célszerűbb szubrutinként megvalósítani, de ügyeni ell arra, hogy a stack véges (16F - 8, 18F 32 mélységű).

#907268 -ra van valakinek ötlete?