Ejj, azt nem tudtam, hogy bootloader nélkül is lehet USB-t használni.
Az egésznek annyit kell tudnia (még annyit se'...) mint ami Gory cikksorozatában van. Mivel közöm nem volt eddig a PIC-ekhez, hát szépen követtem azt ami ott le van írva. Ezért azt hittem, hogy nekem elengedhetetlen ez a bootloader dolog.
De ezek szerint mégsem, viszont ez esetben felmerül a kérdés: hogyan? Semmi egyéb "fordítóra" nincs szükségem, csak simán megírom C18-ban a kódot, beégetem és jó? Gondolom azért valamit kell includeolnom, ami meghatározza az USB specifikus utasításokat?

Gory cikke valóban egy picit azt sugallja, hogy a bootloader elengedhetetlen, de valójában nem az.

A bootloader nélkül is meg kell csinálnod egy csomó dolgot, amitől USB képes lesz a cuccod. Ami te írtál villogo.c-t, az az USB-vel nem csinál semmit. Most jut eszembe, hogy neked ezért akad le a gépről, mert amint kész a firmware átírása és elindul a villogo.c tartalma, az USB kérésekre a PIC többé nem válaszol, ezért választja le az operációs rendszer. Ezután pedig csak a lehúzom-visszadugom segít, hogy ismét felismerje.


Régen néztem már, hogy mi van a Microchip féle USB példaprogramokban, holnap többet tudok mondani, amikot beléjük nézek.


De a villogo.c-ben még mindig PORTD-re írsz. Ezt felejtsd el, és LATD-re írj. PORTD-t csak olvasni szabad.

Tehát ha jól tévedek, akkor a bootloaderes és az anélküli programozás csak az égetés módjában tér el. Leszámítva a későbbi egyszerűbb fw frissítést.
Ezesetben továbbra is követhetem a cikkekben szereplő dolgokat, vagy az ITT található zárójeles megjegyzésből kiindulva, hogy "Bootloader nélkül a linker scriptet és a konfig biteket módosítani kell, csak haladóknak" az következik, hogy mégis csak jobban járnék bootloaderrel, mert így mélyebben bele kell túrni?
Azért mertem csak belevágni ebbe az egészbe, mert Gory cikkében le van vezetve a megvalósítása annak, amire nekem is szükségem van. Tehát ideális esetben csak le kellene másolnom az ottani dolgokat. Ezért nem szeretnék nagyon letérni a jól dokumentált ösvényről.
Lehet, hogy kicsit lehangoló, de nem célom vérprofi PIC-essé válni, ha úgy tetszik a dolgok mostani állása alapján csak ezen projekt erejéig van szükségem rá. Aztán persze, ha úgy adódik szívesen nyúlok majd ismét hozzá, ha a helyzet úgy kívánja, mert roppant sokoldalú eszköz.
Viszont megnézve az MCHPFSUSB példaprogramjait eléggé elbizonytalanító az a temérdek fájl, amit használ. Nem lenne egy utolsó dolog, ha lehetne belőlük szelektálni.
Ezt a gépről leakadós részt nem értem. Nem kell lehúzni, meg visszadugni, csak az eszközkezelőből eltávolítani, mert azt mondja, hogy az eszközt nem lehet elindítani és felkiáltójellel jeleníti meg. De akkor is ezt csinálja, ha csak maga a bootloader van a PIC-en.
A ráégetett program viszont azonnal elindul, amint csatlakoztatom a géphez, és megkapja a tápfeszt.
Mindenesetre először azt kéne eldönteni, hogy bootloaderrel, vagy anélkül. Szigorúan figyelembe véve, hogy abszolút kezdő vagyok, nincsenek komolyabb terveim a későbbiekre, és a megvalósítandó eszköz megegyezik a cikkben levezetett eszközzel.
Ha nincs radikális különbség a kettő között, akkor természetesen hagyom a bootloadert, feltéve, hogy tudok haladni a cikkbeli úton.
LATx, értettem!

Az USB eleg erzekeny dolog. Ha a host kerdeozkodik akkor van 1-2 ms hogy a megfelelo valasszal vissza beszelj kulonben leakadsz. Tehat az egy dolog hogy belinkeled a megfelelo konyvtarakat, attol meg nem garantalt, hogy az eszkoz megfeleloen fog mukodni.

Amugy meg valamit irtal arrol, hogy melyik verziot hasznalod a MC USB stakjebol, es ha jol emlekszem valami regebbi valtozatod van meg?

Az igaz, hogy a gyártó oldaláról letölthető USB CDC firmware működhet a bootloader nélkül, de ahhoz át kell írni egy csomó mindent a linkerben és ha jól emlékszem a firmware-ben is, mert a gyártó bootloaderhez írta meg(amit máig nem értek miért!).
Ezért jobb, ha első körben a cikk alapján haladsz, mert nem túl egyértelmű, hogy miket kell módosítani bootloader nélküli verzióhoz. Délután, ha lesz időm megnézem, hogy miket módosítottam, mert fejből ez nem megy.
Az biztos, és a többiek is leírták már, hogy a bootloadernek semmi köze az USB-s kommunikációhoz, amit szeretnél megvalósítani(az csak egy égető, ha úgy vesszük).
Az USB-s kommunikációhoz a legegyszerűbb a CDC firmware használata(virtuális soros port USB-re leképezve). Bevallom nekem nem sikerült a cikk alapján elindítani annó, mikor először foglalkoztam vele, de biztosan bennem volt a hiba, és azért az is igaz, hogy én bootloader nélkül akartam megoldani. A cikk ettől függetlenül nagyon sokat segített. De legtöbbet a doksikból és a fórumtársaktól kaptam.

Megpróbálok sorrendben válaszolni:

De az eszköz megfelelően működik azután, hogy eltávolítottam, és újra felismertettem. Ebből nekem úgy tűnne, hogy a Windows kavarja meg a dolgokat - bár nem értek hozzá, csak feltételezés -, de akkor viszont érdekes, mert két külön számítógépen is ugyan ezt csinálja.
1.3-as stacket használok, ahogy a cikkben, de fent van a 2.4 is, viszont abban olyat durvítottak, hogy azt sem tudom igazából mire lenne szükségem belőle.
Igen - a cikk szerint haladva - a CDC firmware lenne a következő lépés, de előbb valahogy össze kéne hoznom, hogy a bootloader megfelelően működjön - már ha egyáltalán ő tehet arról, hogy nem tudom USB-n törölni a programot a PIC-ről.
Ezek a negatív tapasztalatok, meg kezdő mivoltom még inkább a bootloader használata mellett szólnak, ezért - egyelőre - nem is nagyon mellőzném, és haladnék is szépen tovább, ha tudnám törölni a programot annak rendje, s módja szerint.
Nekem sem kristálytiszta a cikk, ezért is vagyok itt.

Ha csak az a baj, hogy nem tudod törölni, akkor töröld az LPT-ssel. Majd rájössz később, ha kell, hogy mitől nem megy most. Az ICSP vonalat építsd ki, ha még nincs, mert a nélkül kissé nehézkes a dolog.


Trudnai írta, hogy miért szakad el a vonal. Szerintem is ezért van, és nem a windows az ok.

Nem lehet, hogy többféle USB-s eszköz is megjelenik ugyanazzal a VID/PID értékpárral, attól áll fejre a win eszközkezelője és kell az eszközt újratelepíteni? Megmondom őszintén, nem igazán tudom követni, hogy mi is történt pontosan a próbálkozások során, de igazából erre tudnék csak gondolni a felkiáltójeles eszköz kapcsán.

De mitől lenne belőle több? Lehet, hogy az egészet le kéne írtani, és újra telepíteni. Nekem a PC oldali résszel nem volt gondom, annál inkább a PIC részével.

Viszont most volt egy másik USB-s kalandom, és csak úgy tudtam az elrontott driver telepítést újra tenni, hogy rádugtam az eszközt és úgy töröltem le az eszközkezelőből. Az újratelepítés nem használt addig, amíg ezt meg nem tettem.

2.4-est nem tanulmanyoztam meg, de az 1.3-as az pollozassal oldja meg az USB figyeleset. A cikk is felhivja a figyelmet arra, hogy ha blokkolodik barmi miatt is a firmware, akkor leszakad - en szerintem ehhez kapcsolahto a probema.

Amugy halkan jegyzem meg mikor USB-vel elkezdtem foglalkozni es jatszadoztam a MCUSB stack-el, akkor Vista volt feltelepitve a gepemre es bizony voltak gondjaim - PicDem2 USB atalakitassal bizonytalanul mukodott, tehat nem tudom hasonlo-e a problemad. Az erdekesseg az volt, hogy a PicKit2 is ugyanazt a stacket hasznalta, es az remekul mukodott, szoval nyilvan nekem is csak valami idozitesi problemam volt.

(sjanos nem vizsgaltam meg tuzetesebben a problema forrasat mert inkabb irtunk Szilvaval assemblyben egy sajat stacket...)

Leírom újra, részletesen, mert gyanítom, hogy elbeszélünk egymás mellett.
Volt egyszer a szűz PIC, amire LPT-s égetővel felküldtem a bootloadert. A PIC-et átraktam az USB-s áramkörbe, majd rádugtam a gépre. Ekkor semmi sem történt, mert ugye meg kell nyomni a reset+boot gombokat. Megtettem, ezért a gép szépen kiírta, hogy új hardvert talált. Megadtam neki a szükséges drivert, és hibátlanul be is került az eszközkezelőbe, még screenshotom is van a nagy pillanatról.
Ez után lehúztam és elraktam pihenni, majd másnap ismét rádugtam a gépre. Ekkor szintén nem történt semmi, csak ha megnyomtam a két gombot.
Ez azt eredményezte, hogy a megszokott Windows hang helyett - a Hangok és audioeszközök tulajdonságainál - "Az eszközt nem lehetett csatlakoztatni" nevezetű hangot produkálta, és a tálcán sem jelent meg, hogy új USB-s hardvert talált, viszont Microchip Custom USB Device néven bekerült az eszközkezelőbe, de sárga körben felkiáltójellel, és az Eszközállapotnál "Az eszköz nem indítható el (Kód: 10)" felirattal.
Ezért gondoltam egyet és eltávolítottam (jobb gomb->Eltávolítás, tehát magát az áramkört nem húztam le!), majd a Vezérlőpultban a Hardver hozzáadására kattintottam. Itt magától ismét megtalálta, megjelent a tálcán, hogy új USB-s hardver, aztán egy ablak, hogy "A varázsló a következő eszközt találta: Microchip Custom USB Device".
Ekkor természetesen visszakerült az eszközkezelőbe, ám felkiáltójel nélkül "Ez az eszköz megfelelően működik" eszközállapottal.
Mivel már jónak látta, ezért PDFSUSB-ben a legördülő részben ki tudtam választani a "PICDEM FS USB 0 (Boot)" nevűt, és fel tudtam rá tölteni az ismert LED-villogtató programot. Ez sikerült is, ezután megnyomtam a reset gombot, a Windows a megszokott "Eszköz leválasztása" hangot adta, és el is tűnt az eszközkezelőből.
Most pedig úgy néz ki a dolog, hogyha rádugom az áramkört a gépre és megnyomom a boot gombot (ami az RB4-es lábat húzza földre), a LED elkezd villogni (a resetet nem is kell mellé megnyomni), a Windows pedig a fentieket produkálja.
PDFSUSB-ben pedig Erase Device-ra kattintva a következőket írja ki:
"MESSAGE - Erase Completed.
MESSAGE - Verify Completed.
MESSAGE - Verifying Memory starting from 0x800 to 0x7FFF...
MESSAGE - Erasing Flash starting from 0x800 to 0x7FFF...".
A LED viszont rendületlenül villog tovább.
Ennél részletesebben már nem tudom leírni, elnézést is kérek a hsz hossza miatt!

A LED villogtató program hová fordul, milyen címre?

Ez egy jó kérdés. Hogyan tudom kideríteni?
A program memóriában 000000-tól 0007DF-ig vannak dolgok, afölött csak FF-et mutat a PICDEM FS USB.
Óh, akkor lehet, hogy már értem. Ő 000800-tól 007FFF-ig töröl, a LED villogtató meg a 000800 előtti memóriatartományban van, ezért marad benne.
De hogy tudom neki megmondani, hogy lejjebb kezdje a törlést, közvetlenül a bootloader után, vagy hogy 000800-tól rakja be a bootloaderen kívüli programokat?

Pl. úgy tudod megnézni, hogy az MPLAB-ban belenézel a View->Program memory menűpontba, és ott megnézed, hogy hol vannak utasítások.

Ha emlékszel még, ebben a hozzászólásban próbáltam tisztázni, hogy milyen linker állományt (.lkr) használsz a fordításhoz.

Ha azt használnád, amelyikről szó volt, akkor az én értelmezésem szerint az alábbi sor miatt csak 0x82A-tól kezdődne a programod.

0000-082A-ig NOP
082C-094A-ig pedig a programom
Innen 7FFE-ig szintén NOP
Ezek szerint 00082C-től kellen a memóriában lennie a programomnak?
Mert ha az előzőben írtakat jól értelmezem, akkor mégsem oda pakolja, hanem 000800 alá, ahol viszont nem töröl.
icserny: Nemcsak, hogy azt használom, de a tartalma - így ezen sor is - megegyezik, de azt akkor is írtam.

A bootloadered meddig tart a PIC-ben? Véletlenül nem lóg 0x800 fölé?

"A program memóriában 000000-tól 0007DF-ig vannak dolgok, afölött csak FF-et mutat a PICDEM FS USB."
Azt, hogy ebből meddig tart a bootloader, ill. mettől van a villogóm azt konkrétan most nem tudom, de 0x800 fölött semmi sincs a PIC-ben a PDFSUSB szerint.

az 1.3-al így írd meg a saját programod:

Ezenkívül fontos hogy a fw\demo könyvtárban levő rm18f4550.lkr -t használd linker script-nek. Ennek a lényege ez:

Ekkor nem fogja a saját programod a bootloadert felülírni.

Benjami-nak: Én csak azt nem értem, hogy a _reset() hogy lesz beírva, ha 0x800-0x829 is PROTECTED?

Vzsolo-nak: Nem lehetne a LED villogtatást olyan biten végezni, amit a bootloader garantáltan nem piszkál? (Olyan lábra gondolok, ami nem szerepel felsorolva a bootloader IO konfigurációjában ). A D0..D3 lábakat a bootloader is matathatja, s a bolondját járathatja velünk.

Nekem sem kerek hogy akkor most a protect mégsem annyira protect, de megeszi. A két interrupt vector is protect területen van, az alap linker scriptben is, mégis be lehet irni a goto-kat hogy hová menjen onnan.
Itt van különben a demo2 mchip-es példa erre, a hex-et is mellékelem hozzá, amiből látszik hogy nem rakta tele nop-al a memória elejét. Én ezzel próbáltam a minap az USB-s bootloadert.

Igen, tényleg nem lehet az USB-s programot megakasztani, de ebben az esetben ennek nincs jelentősége, hiszen amíg a bootloader fut addig nem akasztja meg a saját program, amikor meg elindítom a sajátot akkor meg persze hogy leszakad, mivel az nem foglalkozunk az usb-vel. Miután megnyomom a boot+reset gombot újra megjelenik, mivel akkor ismét a bootloader fog futni.

ICD3 belső:

Bővebben: Link

És ezt hova írjam, a programom elejére? Meg ez mit csinál amúgy?
Egyébként változatlanul azt az rm18f4550.lkr-t használom, és továbbra is így néz ki.
Mondjuk az érdekes, hogy MPLAB-ban a bootloadert 07DF-ig jelzi a program memóriában, ugyanis a PDFSUSB is eddig a címig mutat FF-től eltérő értékeket, de viszont a villogóval együtt! Tehát nem csak, hogy 0800 alá kerül a villogó, hanem tényleg felül is írja a bootloadert, pedig ha hiszitek, ha nem tényleg azt a linkert használom, és tényleg így néz ki...

Csak hogy biztosak legyünk benne, hogy a fordító is azt használja, nevezd már át a linker scriptet, és nézd meg, hogy úgy lefordul-e, és változik-e valamit a kód.

Igen, a program elejére, az include és az adatok definiálása után, de a legjobb ha megnézed a pár hozzászólással előbb általam beírt Demo02-t.

Átneveztem, aszondja', hogy "A rendszer nem találja a megadott fájlt.".
Esetleg csináljak screenshotot róla, hogy tényleg jót használok?
benjami: Ok!

Meg bizony! Most próbáltam ki a HID bootloaderrel és pic18f87j50-nel. A HID bootloadernél 0x1000 a határ, s a demo program oda is pakolja a reset és interrupt vektorokat, a bootloader meg szépen beírja.

Ebből számomra az a tanulság hogy a

típusú explicit elhelyezésnél a linker nem hatódik meg a PROTECTION-tól!

Inkább a .map fájlba kukkants bele egy sikeres fordítás után. Nálam jó helyre kerültek a vektorok és a villogó programod is (amit tegnap linkeltél be).

Benjami kiegészítése után már így néz ki. Előtte is megegyeztek a címek, csak az interruptos részek hiányoztak belőle.
Nemsoká beégetem az egészet újra, és reménykedek, hogy most jó helyre kerülnek a dolgok.