Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Azthiszem igazad van!!
 elmélyülök a 887esben! csak kicsit riasztó volt első látásra a demo board
Ha a -demo board doksijában- a 35. oldalon megnézed a rajzot, láthatod, hogy halál egyszerű az egész. Vannak LED-ek, amik most neked kellenek, és még kristály is van rajta, ha a belső oszci után azt is ki akarod próbálni. Azt kell csak megnézned, hogy a LED-ek melyik lábra kapcsolódnak és milyen polaritással, és ennek megfelelően megírni a LED villogtató első programodat. Először az is elég, ha csak kigyullad, mondjuk minden második....
Lenne egy kérdésem a STACK-el kapcsolatban. Ezt a területet a linker fájlban jelölik ki, és 0x100 hosszú. Ez nálam a 0x300 tól kezdődik. Elvileg innek kezdődően hozza létre a fordító a két karakterláncnak a helyet, illetve minden subrutinnak itt osztja ki a lokális változóknak is a terültetet. Egy subrutinban deklarált változó, ha jól tudom addig él, amíg a rutin is él. Gondolom attól, hogy meghív még lejjebb lévő rutinokat, az nem jelenti azt, hogy már nincs szükség a létrehozott területekre?
Úgy gondolom, hogy itt az USB firmware kutyul el valamit, és nem maga a fordító. Próbáltam debuggolni, de eddig nem jöttem rá, hol változik meg a tartalom. Majd ma... A másik, hogy nem értettem milyen jelentősége van annak, hogy a karakter típusú tömbök a valóságban hosszabbak? Azt sem, hogy most mi jelentősége lenne annak, hogy egy ilyen típusú változót hol hozok létre és hol használok(ha csak a subban van szükség rá, akkor miért hoznám létre globálisnak, hogy pazaroljam a RAM-ot?) Ennek nem szabadna így megváltoznia szerintem semmiképpen! A fordítónak tudnia kéne mit hová osztott ki, és csak felszabadítás után oszthatna ki rá más változókat. A gyanúm az, hogy nálam nem teljesen korrekt a linker kiosztás az 512 puffer miatt, vagy az USB firmware valahogy nincs jól megírva és direkt címzéssel rontja el a területet, ami nem a fordító hibája.
Hello mindenki..
Lenn egy rövid kérdésem: pic16f877 40PIN P-DIP tokozású mikrokontrollerhez milyen gyári programozót érdemes venni? A microchip honlapján azt írja hogy a DV164120 PICkit2 StarterKit támogatja a pic16f877 http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nod...010242 de a DV164120 adatlapján az van, hogy: "Low pin count demo board supporting 8/14/20-pin mid range PIC microcontrollers" akkor most hogy van ez? Elöre is kösz a válaszokat.
Na raneztem a DCD fw-re, es ertem mi a baj...
Jol irod, nem kellene, hogy stack elmasszon, es teljesen korrektul irtad le. A gond nem ez, hanem ha megnezed a cdc.h-t, akkor lathatod, hogy a mUSBUSARTTxRam fuggveny nem is fuggveny hanem makro, de nem is ez az igazi gond, hanem az, hogy ez csupan elokesziti a transfert, de az nem tortenik ezen a ponton meg meg... A main-ben valahol vagy interruptban pl van egy CDCTxService fuggvenyhivas minden bizonnyal, es az intezi a transfert, de akkor mar a fuggvenyed reg kilepett, azaz a stack terulet ahova a dolgaid pakolva lettek felszabadult es nyilvan mas dolgokra lett felhasznalva valahol mashol...
Köszönöm, hogy megnézted! Én még ennyire nem értek a C-hez, de most hogy leírtad pontosan értem mi a gond!
Tanulság, hogy a CDC-vel nem küldhetek ki lokális változóból adatot, csak globálisból, vagy rom-ból. Még egyszer köszi!
Lenne még egy kérdésem.
Próbálok 512 bájtnyi memóriaterületet lefoglalni. Ezt tudtommal csak a char típussal tehetem meg, mert nincs olyan a C18-ban, hogy byte típus, vagy mégis? Ha a linkerben beállítok egy területet, pl. 0x600..0x7FF, akkor ide csak 511 hosszú char deklarálható, mivel a 512. a nullkarakter helye. Még is a MC firmware-ban láttam, hogy ugyanerre a helyre 512bájtot deklarál, és le is fordul hiba nélkül. Hogy csinálják? csatoltam az említett firmware-t(komplett work) jut eszembe, az msd_buffer[512] ről van szó...
A PICKit2 minden lényeges PIC-et tud programozni, és nagyon sok, és egyre több PIC-et debuggolni. Tökéletes választás szerintem.
Nem szép megoldás, de a nullkarakter helye is a tiéd. Ha olyan a feladat, hogy a nullkarakter nem játszik szerepet, akkor nyugodtan megcímezheted, és írhatsz is oda.
byte tipus nem létezik alapból (a C a minimális számú alaptipusból indul ki), de ha létrehozod:
Van egy kis felreertes itt szerintem. A lezaro null az a string kezeleshez kell, nem a char tombhoz! Pl. ha ugy definialsz egy tombot, hogy megadod a tomb meretet (char tomb[23]), akkor pontosan annyit fog lefoglalodni (ez esetben 23 karakternyit), a fordito nem tudhatja pontosan mekkora is lesz a benne tarolt adat merete (pl egy string merete). Ha stringet teszel bele akkor kell a lezaro null karakter is, kulonbel buffer overflow hibak tomkelegevel kell szembenezned, akar vegtelen ciklusba is kerulhet a programod emiatt (string kezelo fuggveny keresgeli a nullat de sehol sem talalja es a pointer mindig tulcsordul...). Ezert ebbe csak 22 ertekes karaktert + 1 lezarot tudsz tarolni.
Namost ha nem adod meg a tomb meretet, hanem ugy deklaralod, hogy char tomb[] = "string"; akkor a tomb merete az idezojelben levo karakterek szama + a lezaro lesz... Tulajdonkepp char *pointer = "string"; is lehetne, a fo kulonbseg nagyjabol annyi, hogy a sizeof(tomb) ill sizeof(pointer) maskepp viselkedik - utobbi esetben a pointer meretet kapod vissza. Tehat a valasz, hogy potyo altal emlitett tipus definicio + a tomb deklaracio tokeletesen fog mukodni: typedef unsigned char byte; byte buffer[512]; Egy aprosag lehet meg, hogy a byte-ot mar az USB framework vagy akar a Microchip C18 typedef.h -jaban vagy valahol mashol mar egyszer definialtak, igy a fordito panaszkodni fog hogy felul akarod definialni, igy az tulajdonkepp elkepzelheto, hogy felesleges is - ki kell probalni.
szóval elkezdtem használni a demo boardot és megnyitottam az általuk írt ledvillogtató projectet, és amikor mplabban rámegyek a runra kiírja hogy pk2ERROR 0028:Unable to enter debug mode
mit kéne tennem szerintetek hogy debugolni tudjak?
Úgy érted ez itt találhato http://online.chipcad.hu/www/arak.aspx?group=030113
PICKit2 starter (DV164120) vagy a PICKit2 Debug Express is támogatja a 16f877-et hagyományos 40p-PDIP tokozásban?
A PICkit2 minden kiadásában ugyanaz a PICkit2 programozó van.
Abban térnek el a különböző kiadások, hogy az egyik csak egy programozó, a másik a programozó mellett egy szerelt "low pin count demo board"-ot tartalmaz (starter), a harmadig pedig a programozó mellett egy szerelt "44 pin demo board"-dal van együtt (debug express).
Ja, meg valami, tomb cimzese 0-tol van, igy ertelem szeruen az 512 hosszu tombot 0-511 -ig lehet indexelni...
Ah, értem már. Akkor az a demo board-ra vonatkozik.
Kösz.
LVP es WDT legyen kikapcsolva (erosen javallott hogy a forras kodban legyenek a config fuse-ok! Nem altalam, hanem Microchp altal!), talan van mas is ami hirtelen nem ugrik be. Ha asm-bn programozol erdemes a reset vektort egy nop -pal kezdeni de ez nem minden chip-nel kotelezo. Hirtelen ezek ugrottak be, most rohannom kell remelem mas tud majd segiteni.
Ja meg valami: debug expresshez bizonyara adtak nehany peldat is, azokkal probald meg legeloszor. Ja, meg valami2: MCLR is legyen kikapcsolva - ha jol emlekszem ki kell legyen, es az ugyis a pickit2-hoz kapcsolodik, de el kell olvasni a doksit, mert meg a vegen kiderul keverem a dolgokat es epp bekapcsolva kell legyen hihi
Megnéztétek és elolvastátok mi a problémám?
Nekem nem fordul le az
A microchipes forrásban pedig igen. Ezért merészeltem azt gondolni, hogy ki akarja egészíteni a fordító a null karakter helyével, mivel char típusú ezért 513 bájt helyet akart volna foglalni. Értem már, hogy nem tesz ilyet, de akkor miért nem fordul le? Mi lehet az ok? Hibaüzenet:
linker tartalom ugyanaz, mint a MC forrásban:
Ettől még a fordító pontosan unsigned char típusúnak fogja fordítani, nincs semmi eltérés, csak a lelkemnek, ugye?
A fő probléma nem is ez lenne, lást egyel fentebb.. melleseleg elrontottam a fenti példát, kihagytam a változó nevét, tehát ez nem fordul:
Te, nem adtal meg valtozo nevet
 unsigned char valtozonev[512]; Amugy linker scriptben letra ven hozva egy 512 hosszu szakasz? Section-t is csinaltal hozza? pl ehelyett: ]DATABANK NAME=usb5 START=0x500 END=0x5FF PROTECTED DATABANK NAME=usb6 START=0x600 END=0x6FF PROTECTED ez: DATABANK NAME=b512 START=0x500 END=0x6FF PROTECTED Es a section: SECTION NAME=BUF512 RAM=b512 Utana mar elmeletileg csak annyit kell csinalni, hogy: #pragma udata BUF512 // buffer terulet kijelolese unsigned char buffer[512]; #pragma udata // vissza a normal udata szekciora
Még valami.
Értem, hogy azt mondod, nem foglal a null karakternek helyet, de akkor miért írja azt, hogy a 0x201-edik címre próbáltam meg helyet foglalni(az már 513 bájtot jelentene!)? Ha 511 bájtnyi helyet foglalok, akkor a Watch ablakban 511bájtnyi, azaz 0x600..0x7FE-ig tart a terület. Ilynekor nincs hibaüzenet. Ha 512-őt foglalnék, akkor meg a fentieket üzeni. Nekem erősen gyanús, hogy még is foglal a típusnak megfelelően helyet a null karakternek. Lehet, hogy ezt valahol a project beállításainál meg lehet határozni? Számomra alapból teljesen elfogadható lenne a dolog, hiszen karakter típusú tömböt deklarálok, ami egyel hosszabb kell legyen, mint a tárolni kívánt karakterlánc hossza. (annó amikor érintőlegesen C-t tanultam PC-n ez így volt azt hiszem. Egyébként a címzéssel tisztában vagyok...) Szóval?
Tudom nincs sok időd, és én is öntöm itt a kérdéseket, de írtam (igaz potyonak), hogy elszúrtam(természetesen csak itt, nem a kódban!
), és javítottam.A liker fontos részét mutattam. A MC firmware-ben sincs külön szekció csinálva, még is műkszik, de ha készítek, akkor sem megy a dolog. A szekció helyett én így deklarálom(ezt is MC-éktől láttam és jól működik olyan tekintetben, hogy a megadott címtől helyezi el a változót...)
Ok ok, mar latom en is csak ugy tunik meg nem frissitettem oldalt mielott valaszoltam
Szoval ha 511-et irsz be akkor 511 byte-ot fog lefoglalni (0-510 indexekkel). Az a gyanum, hogy az SD_Buffer_512[512]; utan nincs kiadva egy sima #pragma udata ami ugye torli, hogy mit jeloltel ki es utana meg van egy 1 byte-os valtozo definialva. Nezd meg hogy ahogy irtam peldat ott kozvetlen a buffer deklaracio elott van a szekcio kijelolve, es utana egy ureg pragma udata. Nekem ugy is fordul ahogy Te irod a pragma udata akarmi=ramcim-mel, ugy is ahogy en, szekcioval...
Bingó! Adnék 50 pontot, de ugye ez itt már elszállt, hacsak nem olvassa egy kedves modi és megtenné ezt nekem!
Volt egy ilyen sorom a 512 deklarálás után:
Ezt én tökéletesen figyelmen kívül hagytam, hogy itt bizony egy bájtot lefoglalna a Flag bitjeimnek! Hiába van még mit tanulnom!  Köszönöm a segítséget! Egyébként ezután, hogy ezt a helyére tettem, bármilyen linker verzióban fordul, legyen az szekciós, vagy direkt címmengadásos pragma.
Az a linker üzenet nem azt jelenti, hogy az az egy struktúra lett 513 byte, hanem azt, hogy abba a section-ba 0x201 hosszú adattartalom van definiálva _összesen_, ami nem fér be a linker scriptben a section-nak lefoglalt helybe.
Nem lehet, hogy véletlenül ebbe a #pragma szakaszba belekerült még egy egy byteos változó is akaratodon kívül?
Igen, megoldódott, és pontosan fogalmaztál, akaratomon kívül. A típus példányosítása nem hasonlított egy deklarációra, ezért valahogy ott maradt. Ez a rutintalanságom miatt történt, de jó tanulópénz volt...
Nem is baj, hogy leirtad, igy legalabb ertheto, hogy mi is tortenik ott es miert kell az az ures udata pragma.
Idézet: „Adnék 50 pontot, de ugye ez itt már elszállt, hacsak nem olvassa egy kedves modi és megtenné ezt nekem!” Orulok, hogy megoldodott, de meg ne probald ezt a pontozosdit  Nagy marhasagnak tartom - hacsak nem lehet levasarolni a HEstore-ban, ha igen adhatsz 500-at is
Hello, olyan kérdésem lenne, hogy pic18f4550-et szeretnék programozni, de valami miatt a B port 5-ös bitje ha kimenetre van állítva, nem hajlandó működni. Valakinek volt már hasonló tapasztalata, vagy nem állítottam be megfelelően valamit?
|
Bejelentkezés
Hirdetés |
