Hali!
Olvastam valahol még régebben (talán ebben a totyikban), hogy a PCL értékét nem ajánlott módosítani 18F széria esetén (pl.: "ADDWF PCL").
Csak én emlékszem rosszul, vagy tényleg van valami indok rá?
Szerk.: az adatlapban van rá példa hogy lehet használni, csak nekem valamiért rémlik, mintha óvatosan kéne vele bánni.

Szia!

Minden további nélkül, ugyan úgy használható, mint a 16F -eken.
Két apró eltérés mégis van:
- A 18F -eken egy utasítás általában 2 byte, a call , goto, movff, lfsr és még néhány azonban 4 byte. A memória pedig byte -osan számolódik. Páratlan címre nem szabad ugrani.
- A movf PCL,w utasítás feltölti a PCLATU, PCLATH regisztereket. Sajnos az addwf PCL,f nem.

Köszi a választ!
Tulajdonképpen a RETLW utasítással akartam tömbkezelést megvalósítani, de nem olyan egyszerű, ahogy azt az adatlap írja (legalábbis az MPLAB szerint).
Az adatlap ezt írja:


Ezzel a mintával az MPLAB SIM nulláza a PC felső bájtját, és oda ugrik, ami az alsó bájtban van.
Tudom van a táblás módszer, azt szoktam használni, de mondom kipróbálom már ezt is...

- A Table címke után mentsd el a W -t, olvasd ki a PCL -t a W -be, aztán hozd vissza a mentett értéket. Máris működni fog az addwf PCL,f.
- A Table címke után mentsd el a W -t, töröld a PCLATU regisztert, töltsd fel a PCLATH -t a retlw k0 címének magas byte -jével. Hozd vissza a mentett értéket. addwf pcl,w (átvitel kezelése a PCLATH regiszterben) movwf PCL.

Hali!
Javaslom Neked az icserny PICCOLO projektjét. Ott példaprogramokkal illuszrálva ilyen feladat. (Én is hasonló projekten ügyködöm, PIC18f4550-l.)
USBDeviceTasks(); meghívása interrupt szinten történik, a ProcessIO(); pedig a főmenü végtelen ciklusában.
A PICCOLO projektben saját függvénnyel történik az adat küldés a PC-fele pl: outdec(Aadat2,0);
Üdv.

Köszi a tippet, a PICCOLO tényleg nagyon jó, már dolgoztam vele. A hello-int projektet kipróbáltam, de van néhány dolog amit nem értek.

1. Ki van kommentezve a piccolo_config.h-ban a USE_INTERRUPT, ennek ellenére fordításkor mégis azt írja hogy "USE_INTERRUPT:definiált". Próbáltam megkeresni hogy melyik másik file-ban van elhelyezve ez a definíció, de nem találtam meg.

2. Nem értem hogy az interruptos változat miben más a pollingosnál. Mert itt is megvan a while(1) hurok, a c=usb_cdc_getc(); függvényhívással. Én pont ezt szeretném megoldani, hogy a főprogramban ne kelljen várakozni az usb_cdc_getc()-vel az adatra, hanem ha jön adat, akkor azt lekezelem, de előtte és utána fusson tovább a főprogram.

Sziasztok!
Nem találtam olyan témát, ahová ez beférne, és olvasott is lenne, ezért itt teszem fel a kérdést.
Van egy tönkrement motorgyujtásom, és szeretném ujjraépíteni. Van benne egy MB88503H mikrokontroller. Tud valaki segíteni, aki foglalkozott már hasonló kontrollerel?

Hali!
1. Az interrupt definiálása az MPLAB project opciójában történik, ezért definiált fordításkor.
2.
ha kiveszed a karakter várakozó ciklust, akkor nem fog várni. Persze a ProcessIO(); hívásának maradni kell.
A projekt USB használata fejezet részletesen leírja a ProcessIO() és az USBDeviceTask() függvények működését. Lényeg az hogy a ProcessIO () az USB buffert kezeli, a DeviceTask () pedig a kapcsolat fenntartását.
Üdv.

Köszi, tényleg ott van definiálva, ez így világos. Viszont a második kérdésemet egy kicsit lehet hogy félreértetted. Nekem nem azzal a várakozással van gondom, hanem ami utána következik:

c=usb_cdc_getc();

Mert ha a számítógépről nem küldök semmi adatot, akkor a program itt megáll, és vár akár végtelen ideig. Én azt szeretném megoldani, hogy ha netán nem küldök adatot a számítógépről egyáltalán, akkor fusson tovább a főprogram, és ha pedig van bejövő adat, akkor azt fogadja.

Hali!
Nem értettem félre és nem ott várakozik hanem abban a ciklusban amit beidéztem. Amennyiben azt kiveszed (a ProcessIO() marad) akkor folyamatos a program.
Üdv.

Ha nem kell minden projektben, akkor kényelmesebb projektenként beállítani, a Project/Build options/Project menüben. (Ezért nem találtad az állományokban!).

Hasonló a helyzet az USE_USB-vel is: az is definiálható a konfigurációs állomány helyett a projekt opciók között...

Csak annyiban, hogy az USBDeviceTasks() függvény meghívása megzsakítási szinten történik. A felhasználói program main() függvényében nem vehető észre a különbség, mert az idevonatkozó részletek a ProcessIO() függvényben vannak elrejtve (feltételes fordítással iktatjuk be azt, hogy pollingos kezelés esetében a ProcessIO() minden lefutáskor hívja meg az USBDeviceTasks() függvényt. Lásd: piccolo_usb.c).

Akár pollingos, akár interruptos a kezelés, a főprogramban rendszeresen hívogatni kell a ProcessIO() függvényt, mert a karaktereket az USB buffer és a felhasználói karakterbuffer között ez közvetít. A különbség annyi, hogy interruptos esetben nem időkritikus a dolog, pollingos esetben viszont elakad az USB kapcsolat, ha túl sok idő telik el a ProcessIO() két meghívása közben.

Erre használható az usb_cdc_kbhit() függvény. Arra azonban ügyelni kell, hogy a ProcessIO() hívásra rendszeresen sor kerüljön.
1. Vagy usb_cdc_getc(), usb_cdc_putc() hívás által,
2. Vagy a delay_ms() függvény meghívása által,
3. Vagy explicit módon, beiktatva egy ProcessIO() hívást a főprogram végtelen ciklusába. (A te programodból ez kimaradt, azért nem működött rendesen.)

Köszönöm a választ, ezt ki is próbálom!

No ki is próbáltam, így már kicsit körülményesebb a használata, maradok a táblás módszernél.

Köszönöm a segítségeteket! Egyedül az nem világos még az USB interrupttal kapcsolatban, hogy tulajdonképpen mi is a megszakítást kiváltó ok? Ha küldök egy byte-ot a PC-ről, akkor végrehajtódik a hi_isr() függvény?

Viszont arra jöttem rá hogy egy kicsit más az oka annak hogy nem működik az áramköröm. A nyomógomb tökéletesen működik ha nem használok USB-t, de ha rá van kötve a PC-re, akkor multiméterrel mérve azt tapasztalom, hogy "lebeg" az RD1-es láb 0-5V-ig. Ez mitől lehet? Lehet valahogy segíteni rajta?

Ezt ne feszegessük, mert én sem ismerem minden részletét. A PC rendszeresen küld valami üzenetet az USB vonalon (akkor is, ha nem küldesz adatot, de hogy mi az, amit lekezel a hardver, és mi az, ami kiváltja az interruptot az számomra is homály. Mindenestre ha küldesz adatot, az biztosan okoz megszakítást.
Ehhez valami kapcsolási rajzot kellene látni.

Az USB nem byte szintű kommunikácó. A kommunikáció alapja egy távirat (frame). A kommunikáció buffereken keresztül történik. Akkor lesz megszakítás kérés, ha változik az USB busz állapota, egy távirat vétele befejeződik, hiba törtlént stb. A lehetséges megszakításkéréseket szépen leírja a 18F2550 adatlapja a 17.5 fejezetben...

Köszönöm a válaszokat!
Tényleg nem akartam annyira belemenni a mélységekbe, és az adatlapban tényleg minden benne van, igazából csak arra vagyok kíváncsi, hogy meg lehet-e azt oldani, hogy a main függvényben nem foglalkozok az USB-n érkező adatokkal egyáltalán, hanem helyette átrakhatom-e az adatok feldolgozását egy olyan függvénybe (talán ez lenne a hi_isr() ?), ami majd akkor hajtódik végre, ha tényleg van bejövő adat az USB-ről?

A másik problémámra van esetleg valakinek valami ésszerű magyarázata? Hogy miért gajdul meg egy különben tökéletesen működő digitális bemenet pusztán az USB használatától?

Hali!
Idézet az ominózus projekt leírásából:

Milyen tápot használsz? Stabil táp kell, a dugasz tápokkal csak óvatosan. A 100nF kondik a PIC tápoknál meg vannak?
A táp és az USB +5V-ja nincs összekötve?
Amennyiben jó a kapcsolásod (nincs benne zárlat és biztos vagy magadban) esetleg megpróbálhatod a PC USB-röl az áramkör táplálását.

Hali!
Biztos egyszerű, de pillanatnyilag számomra ismeretlen kérdéseim vannak:
1. hogyan lehet tudni az USB, vagy USART bufferben lévő karakterek számát?
2. kiolvasás után hogyan lehet kiüríteni a buffert?
Az a gondom hogy jelenleg kiolvasás után ott maradnak az adatok mindaddig amíg nem érkezik következő. Folyamatos adatérkezés esetén nem lehet tudni mi a helyes adat.
Üdv.

Ja, hogy ezek gondot jelenthetnek? Mert amiket leírtál lehetséges hibákat, azok mind megvannak, de eddig nem jelentett semmi gondot. Az USB-ről megy a táplálás, ebből kifolyólag össze van kötve a táp és az USB +5V-ja, de nincs 100nF kondi. Most nem tudom ezeket kijavítani, hétvégére elutazunk, utána javítgatok rajta, remélem megoldódik ettől a probléma, köszönöm a segítséged!

Sziasztok! Van egy 18F4550 es bootloaderes pic-em és hozzá egy fejlesztőkörnyezet. Régóta írok rá progikat. Egy hete pwm es ventillátor vezérlésre használtam kb folyamatos üzemben, de semmi gond nem volt, a hardverrel nem lehet gond, viszont ma írtam egy más jellegű programot, de nem tudom feltölteni, mert nem áll fel az USB kapcsolat... Van egy pickit2 klónom, a bootloadert beégettem mégegyszer a 18F4550 be, de miután belép bootload módba a pic, csak a D port 0 ledje világit... A minap tettem fel a Nod32 vírusírtót, lehetséges hogy az usb drivert blokkolja? vagy mi lehet a gond? Kérem segítsen valaki! :O Köszi!

A VUSB lábon a 470 nF-os kondenzátor renben van (nem szakadt le)? Rendes tápfeszültséget (3,3 V körül) mérsz rajta? A D+/D- vonalakon nincs szakadás, vagy zárlat? Az oszcillátor jó frekvenciával üzemel?

Sziasztok!

Adott program ami elég szertagázóan figyel egy bemenet. Hogy tudok ennek a bemenet "virtuálisan" elid
nditan?
Még tisztábban jelenleg IN1 RB1- figyel (több helyen a programban) ezeket nem szeretném modositani.
Amit szeretnék: IN1 RB1- változtatás (idozités, magas alacsony szint stb.) -figyel.
Vagy esetleg RB1- változtatás (idozités, magas alacsony szint stb.) - IN1 -figyel.

Igazából nem mértem ki, mert az eredeti programot futtatta rendesen, és nem volt az áramkör olyan környezetben hogy sérülhessen fizikailag... Tehát minden működött, csak miután bootload módba léptettem, nem villognak a portd 0 és1 ledjei (amik ilyenkor szoktak) hanem csak a portd0 világít folyamatosan... Próbáltam úgy hogy pickit 2 vel töröltem a bootloadert, és rátettem egy "nyers" teszt progit az működött rendesen... De Valamiért arra gyanakszom hogy a vírusírtóm blokkolhatja, mert a legutóbbi sikeres bootloados feltöltés óta csak a vírusírtó változott. :/ Egyébként a 18F4550 5V os pic

Szia!

- A pic uart -ja esetén valamelyik PIR regiszter RCIF bitje jelzi, ha van karakter a vételi bufferben. Egyes típusokban a vételi buffer egy fifo, az RCSTA regisztert az RCREG előtt kell kiolvasni (a további feldolgozást egy mentett értékkel végezni). Az RCREG kiolvasása lépteti a fifo -t, az RCSTA és RCREG már a következő adat szerint áll be.
- A CDC USB uart esetén a getsUSBUSART() függvény visszatérési értéke megadja az átmásolt karakterek számát.

Üdv!
Szeretném egy 10 bites A/D átalakitó eredményét egy 4 számjegyű multiplexált kijelzőre kiirni.8 bit-ig megy is a dolog,itt viszont elakadtam.Nem programot,vagy macrot kérek,azzal majd megszenvedek én,csak valami útbaigazitást.

Szia!
Két kivezetést használhatnak fel a USB -rutinok:
#define usb_bus_sense PORTAbits.RA1
#define self_power PORTAbits.RA2

Nézd meg a beállításukat. Véletlenül nem a nyomógomb bemenetére van valamelyik beállítva?

Szia!

A 10 bites bináris értéket 4 digites BCD kóddá kell alakítani. Egy kis segítség...

Kössz ez gyors volt,pont ilyesmire gondoltam!

Hányszor, de hányszor belinkeltem már... Nekem az osztás és kivonogatás nélküli, léptetős, pakolt BCD megoldás tetszik a legjobban. Rugalmasan bővíthető akármekkora számokra...