Mackósajt!

Én azt gyanítom, hogy ez a hardver a PIC kiterjesztett részeként funkcionál, év vagy benne fut a kód egy része, vagy csak baromi gyorsan tud kommunikálni a PIC-el. Már csak azért is, mert a full speed USB kapcsolat sebessége messze nem indokolná azt a lassúságot, amit az icd2, pickit3 ad az iscd3, 4-el szemben.

Köszi a linket! Hát ez teljesen rendben van sebességügyileg, úgy tűnik! Pedig ha jól rémlik, ott is csak full speed kapcsolat van az USB-n...

Adni akartam a Microchipnek még egy esélyt, ezért feltelepítettem az MPLB X-et, az XC8 fordítót és az MLA legújabb kiadását.

Jól látom, hogy ez a kombináció nem támogatja az USB HID bootloader használatát? PICDEM FSUSB (PIC18F4550) kártyához az USB Device HID Custom demót próbáltam volna...

Támogatja. Az xc8 linker beállításoknál, az "additional options" kategóriában a Codeoffset-be kell beírni a 0x1000-t.

Ha valami nem működik az új fordítóval, az MPLAB-X-be pár kattintással simán be lehet integrálni a régi fordítókat is, pl. a C18-at, a hi-tech C-t.

Köszönöm a segítséget! Így tényleg működik.
A tőled kapott Codeoffset kulcsszó alapján találtam a témáról egy hasznos anyagot is: Linking PIC18 Bootloaders and Applications

Ha majd emlékszel erre +1 héttel később is, kérnék egy gyors véleményezést, milyen benyomásaid voltak az xc8 jelenlegi minőségéről (és hogy a free-t vagy a fizetőset használtad-e) egy hét után.

Az XC8 ingyenes verzióját használom, sokat nem várok tőle, s nem is szándékozom nagyon belemerülni.

Én úgy tudom, hogy az XC8 oly módon készült, hogy az MC felvásárolta a hi-tech C-t készítő céget. Az addig külön-külön 16Fxxx-hez és 18Fxxx-hez készült hitech C fordítókat egybe gyúrták és átkeresztelték XC8-ra. Ez elég nyilvánvaló, ha megnézzük a hitech C és az XC8 szintaktikáját. Ugyanaz a kettő.

Sziasztok!

Nem tudom hogy kiknek mond újat a dolog, de egy hangyaf... lehet rövidíteni a programozási időn, ha a Tools->Options->Embeded->Maintain active connection to hardware tool checkbox-ot bepipáljuk.
Mert így ugye folyamatos kapcsolatot tart és nálam így kiesett a programozás előtti PIC lekérdezés (hogy azt akarom programozni ami be van állítva). És elvileg a régi v8.xx is ezt csinálta ezt nem tudom nem nagyon használtam.

Egyébként Itt olvastam erről.

MLA tapasztalat érdekelne.

USB host / mass storage device (lba szektor írás / olvasás elég) kezelés kellene. Találtam több helyen is, pld 2012 februári mla-ban "USB\Host - Mass Storage - Simple Demo"-t, de hoszabb távú tapasztalatom nincs vele. Ha bárki használt pen drive-ot pic-re dugva huzamosabb ideig bármelyik mla-val, örülnék tippnek, melyik mla-t használta.

Miért gondolod, hogy aggódni kellene emiatt ?
Megírod, kipróbálod..., s ha megy hibátlanul -> örülsz neki!

Megkérdezték tőlem, hogy megesküszöm-e a fejemre, hogy nem lesz vele baj? Nem mondtam igent, mert nem próbáltam még ki huzamosabb ideig. Jellemzően annak a korszaknak az mla-ja normális, van benne bizalmam annyira, hogy rá fogom szánni az időt, ha oda kerül a történet. De ha jelentkezne itt bárki, hogy ő bizony próbálta, és über gáz, lehet, egyáltalán meg sem nézem. A lehetőségek microSD / spi port kontra külső pen drive / usb host port. USB port még van szabadon, az spi-k sajnos elfogytak, és kellemetlen lenne felszabadítani egyet. Dióhéjban ennyi a történet.

Találtam neked egy projektet, nézd meg, hátha segíít!
Douglas Katz and Fred Kummer: Using the PIC32MX250F128B as a USB Ho...evices

Köszönöm a tippet. A projectet megnéztem, ők egy 2011 ápr 26-os project állapotot használtak fel az mla-ból (nem "hivatalos" kiadás). Ha semmi más nem működik, észben fogom tartani, hogy megnézzem azt is. Szerencsére nekem mx795-höz fog kelleni, nem kell majd átalakítgatnom a regiszter címeken.

Néztem a "hivatalos" mla-kat, az utolsó verzió, ami még supportol c32 fordítót is, 2012 ápr 3-as. Az után (2012 jul 18 és későbbi), már csak X support van.

Üdv fórumozók!

Egy nagy problémám lenne ( remélem jó helyre írok ) egy PICDEM net 2 DEV BOARD-al amiben egy PIC18F97J60 található. Van hozzá egy MPlab ICD3-as In-Circuit debuggerem. Letöltöttem a legújabb MPLAB x IDE-t és a legújabb XC8-as fordítót. Feltelepítettem az ICD3-hoz tartozó USB drivert is. A problémám az , hogy a Microchip TCP/IP stack demo kód , ami jár hozzá ,

Amit innen töltöttem le: http://picforum.ric323.com/viewtopic.php?f=19&t=449
Itt a PICDEM net 2 DEV BOARD : http://www.microchip.com/Developmenttools/ProductDetails.aspx?PartN...163024

Feltöltöm , a ledek elalszanak , és az LCD kijelzőn egy nem DHCP által kiosztott IP-t mutat , amivel már a weboldalt nem tudom elérni. Viszont ha az előre felépített ( Prebuilded ) programot töltöm fel rá , ami elvileg ugyan az , azzal tökéletesen megy. A baj hogy az előre épített programot nem tudom módosítani mivel az már gépi nyelven van. Nem pedig C-ben vagy Assemblyben,

A picforum.com link hibás, vagy nemlétező témára mutat.

Oda került egy pontos vessző valahogyan , elnézést. Ennek már jónak kell lennie. ^_^

Pic demo code

Egy zip fáljban található az "elvileg" működőképes DEMO code.

Ha nagyon van gyomrod oknyomozni, nyilván idővel ki lehet deríteni a probléma okát, de segíteni az akkor sem fog rajtad. Egyszerűbb másik utat választani. Az xc fordítót, és az mplabx-et én nem igazán javasolnám, ha nincs kedved a lelki nyugalmadat feleslegesen fizetni ki érte. Jobban teljesítenek a régebbi cuccok.

Az mc saját dev boardjaihoz temérdek sok példakód készült, azok működőképesebbek. Mla libet találsz itt: Bővebben: Link, 2013 ápr 3 vagy előző libet tölts csak le. Kibontod, feltelepíted, bekotorsz a könyvtárba a példa projectek közé, lesz ott minden, mint Disneyland-en. Környezetnek a régi mplab-ot (MPLAB IDE v8.92) itt találod: Bővebben: Link, fordítót szintén ott "MPLAB C Compiler for PIC18", 3.46-os az uccsó. (Én magam az sosem használtam, ha véletlenül baj lenne azzal a c18 verzióval, majd a többiek rám szólnak De leeht bátran használni a régebbieket is.)

Ha jól értem,
- van egy kártyád
- van a Microchip honlapján egy AN1921 alkalmazási mintapélda (TCP/IP Lite), ami nem a te mikrovezérlődhöz készült.
- Valaki viszont átírta ezt PIC18F97J60 mikrovezérlőre és a picfórumon közzétette

Ezt a csomagot nem sikerült nálad működésbe hozni. Remélem, figyelembe vetted, hogy ez nem a beépített Ethernet vezérlőt, hanem az ENC28J60-at használja (ezt írja az ipse a fórumon).

- A bináris fájl, ami működött a kártyádon, az föltehetőleg nem ebből a picfórumon közzétett csomagból származik, tehát nem tudhatjuk, hogy a fórumon talált csomag egyáltalán működőképes-e, s ha mégis igen, akkor miért nem...

Az általad letöltött projekthez igényelt szoftver komponensek (MPLAB X v4.0x, MCC plugin, XC8 v1.4x, TCPIP lite library for MCC) közül az MCC plugin számomra ismeretlen. Nálad telepítve van?

Dev board kérdés.

Ethernetes pic32 + külső 100 mbps phy 4 adatvonalasan bekötve. Találkozott bárki olyan dev boarddal?

Amiket én találtam, mindenütt csak 2 vonalasan van bekötve a phy, és az a gyanúm, hogy az valójában nem működik 100 mbps-el. Vagy legalább is anno voltak róla erraták, de azóta azok a hírek már a revision log-ból is eltűntek (kicsit furcsa).

Úgy értesültem róla hogy a kártya az ENC28J60-at használja , ami meg is van adva a programkódban. Fel van telepítve az MCC plugin is , ami valójában csak egy bit szerkesztő plugin , nem sok hasznát veszem kezdő ként. A fickó aki feltöltötte ezt nekem , azt mondta hogy ő mégegyszer kipróbálta amikor írtam neki hogy nem jó , és neki ment , ugyan ezzel a boardal.

Letöltöttem a régebbi MPLAB-ot , pontosan a v8.92-t amit írtál , a c ompiler for pic18 az nem megy fel a gépemre valamiért , gondolom mert 64 bites win10 van. Egyik verziót sem tudom telepíteni. Nos a lényeg az hogy a régi MPLAB nem támogatja a .X kiterjesztésű fájlokat , amik alap esetben mappák a windowsban. Így nem tudok bele tölteni egy egész projectet , csak fájlonként , viszont úgy sem jó.

Oh bakker azt elfelejtettem Nálam még mindig win7 van. Mplab alatt X project nem fordul. Mplab alatt csak "mezei" c projectek voltak.

Tegnap egy fura jelenséget vettem észre, hibakeresés közben. Ha megváltoztatok egy a program memóriában tárolt 4 elemű konstans tömböt, akkor a fordító ennek függvényében képes a fordított kód valamely részét is megváltoztatni úgy, hogy közben maga a forráskód semmit se változott, csak annak a bizonyos tömbnek pl egyik elemét 0x00AA-ról pl 0x00AB-re megváltoztatom!
Nem is foglalkoznék az egésszel akkor, ha ebből a két állapotból az egyik nem lenne alapban hibás! Tehát nem pusztán csak mondjuk máshogy optimalizált(ami nem lenne kizárt), hanem konkrétan rosszat fordít olyankor. A csatolmányokban látható is a hiba...egy if...else ág mindkét ágába betette az RCALL Letolto utasítást, holott annak evidens módon nem úgy kell lennie. A másik képen látszik, milyen amikor jó. A két fordítás között csak annyi változás volt, hogy az említett konstans tömb egyik értékét átírtam.

Találkozott már valaki hasonlóval ? Mi a fene lehet ez ?

MpLabX, xc16.

A problémát ilyenkor okozhatja egy túlcímzett tömb is. Ha egy tömb 10 elemű, és te a 11. elemét olvasod ki, akkor visszakapsz valami adatot, ha ugyanide írsz is, akkor könnyen lehet, hogy egy másik változó, vagy bármi más értékét módosítod. A compiler ilyenekre nem figyel.

Nem figyeltél! Nem futáskori problémáról beszéltem, hanem fordításkoriról!

Azóta kielemeztem a problémát...érdekes eset, egy példája annak, amikor mindenkinek igaza van. A fordító valóban rosszat fordít egyik esetben, de nem hibásan, hanem mert egy logika szerint optimalizált! Ugyanis a konstans tulajdonság miatt a feltétel mindig egyféleképpen teljesül az if/else ágban, így ő jogosan gondolta, hogy felesleges az oda, kioptimalizálta.
Igen ám, de jelen esetben ez nem megengedett, ugyanis a normális működésnek az is állapota, amikor az a konstans más értékű! Ekkor kellene ugye az else ág is már, amit viszont kioptimalizált. Nyilván a fordító nem tudhatja, hogy egy konstans valaha is meg fog változni...

Egyébként van arra valami mód, hogy a forráskódban, egy kód részletet kivegyünk a modulszintű optimalizáció alól ?

Hat ha egyszer konstans, akkor annak nem lehet mas az erteke, mint amit a forraszszovegben megadtal. Pont ezert tudja kioptimalizalni. Nem ertelek.

Elképzelhető, hogy annyira félrecímzel egy tömböt, hogy nem csak a RAM-ban elfoglalt adatokat tudja felülírni?
Örülök, hogy meg lett a probléma. Ezek szerint a konstansod mégsem konstans...