Az adatlapja mondja meg a tuttit.
Nagyjabol 10ezerszer, de vannak ezer-szazezer kozotti ertekuek is.
Probaljatok meg kicsit nagyobb fesszel. Persze a gyari egetok nem biztos, hogy tudjak ezt...

Van egy ilyen sorom (MCC18):

Hozzá egy ilyen figyelmeztetésem:


A Pub_Buffer_512_ptr-t így hozom létre:

A Pub_Buffer_512 a Linker fájlban létre van hozva.

Kérdezném, hogy ebből milyen gond lehet? Hogy érti azt, hogy gyanús, kétes mutató konverzió?

Azt hiszem a getsUSBUSART egy char* pointert var, es nem tetszik neki, hogy unsigned-et kap. probald meg castolni, vagy eleve char*-nak definialni a puffert es/vagy a pointert.

Ez a sor igazából felesleges, mert a tömb neve eleve a tömb első elemére mutató pointerként viselkedik. Tehát írhatod így:

Annak oka van, hogy így kell deklarálni. Ha megnézed, ez egy 512bájt hosszú RAM területet fed le, másképp nem lehetne elrni minden elemét.

Igazad lehet! A getsUSBUSART 64 bájt méretet vár max.(gyári USB firmware)
Azt hiszem előbb át kell mozgatnom egy 64bájtos pufferbe a megfelelő szeleteket, és utána kiküldeni, mert egyébként nem fogja érteni melyik címre hivatkozom. A baj csupán az, hogy már nem sok memória van. Esetleg lemozgatom az alsó 64bájtra sorban a szeleteket...
A C-t csak nemrég kezdtem el használni, ezért nem igazán értem a castolást, és hogy az miért lenne megoldás. Gondolom segítesz!?

Jobban átgondolva, hülyeséget írtam, azt hiszem.
Ennek semmi köze, hogy mekkora a puffer mérete.
Ez egy memória cím, nemde, csak a pointer esetében átnyúlhat több bankon. Nem tiszta, hogy ez a C-nek miért jelent gondot, mikor asm-ban FSR-el le lehet kezelni simán. (megint nem szeretem a C-t! )

Én el birom érni akkor is...

Hogyan? Én létre sem tudtam hozni, amíg nem turkáltam a linkerben! Az USB CDC-re ültettem a progit...

Egyébként van egy érdekes tapasztalatom. Az USART Rx és az SPI SDO lába közös, de nekem mindkettő kell. Ezért úgy gondoltam felváltva fogom használni. De ha egyszer inicializáltam az USART-ot, hiába tiltottam le és váltottam SPI-re, nem működött az SPI vonal. Aztán kínomban az RC7-et az SPI mód váltáskor beállítottam kimenetnek és működik.
Ebből arra következtetek, hogy az USART kiválasztásakor az Rx vonal automatikusan bemenetre konfigolja a lábat(ezt tudtam is, csak nem sejtettem, hogy úgy is hagyja!), viszont az SPI nem konfigolja magától kimenetnek az SDO lábat! Köszönöm Microchip!

Igazából ez egy védelmi figyelmeztetés a fordítótól, mert a char és az unsigned char két különböző értéktartományt tud tárolni (-128..+127 illetve 0..255), bár mindkettő egy bájtos. Char én unsigned char esetén nem olyan vészes, de ha pl. egy int-re mutató pointert váró függvénybe char-ra mutató pointert adsz be, és az oda pakolgat adatokat, akkor ott minden második bájt felül lesz írva. A castolás pedig gyakorlatilag a védelem megerőszakolását jelenti.

Pl. csinálhatsz olyat, hogy

(bár ez utóbbi sor szerintem továbbra is felesleges)

A linkerbe én is belenyúltam:


Azután pedig:


Szimulátor szerint működik...

Azt hiszem ha ROM-ra nyulkalsz akkor nem felesleges, ahhoz mindenkepp kell a pointer. Azonban valoban van egy bank korlat ebben az MC18-ban. Nem egeszen ertem miert nem tudtak megoldani, hisz epp ez lenne a lenyege egy magas szintu nyelvnek Na mindegy, hogy ez hogyan lett pontosan implementalva az MC18-ban nem tudom hirtelen, nemsokara utana nezek, de mindenesetre elmeletileg lehetne igy pointert gyartani a tombbol ahogy mondod, potyo - csak ezek a PIC-es C implementaciok nagyon furan viselkednek neha.

Igazad van, linker script modositassal mukodik a dolog, akkor vissza szivtam amit mondtam

Részlet a kezelési útmutatóból! Én ebből indultam ki


Mindezt a "//bár ez nem kell" megjegyzésedre írtam...

Még valami: Miért használ a microchip a firmware-ben sima chart, mikor címre számít? Szórakoznak az emberrel? Hol láttak ezek már előjeles címet? Vagy én nem értek valamit?

Ebben az az érdekes, hogy a pointer sem más, mint egy változó, ami egy memóriacímet tárol. A tömb neve pedig a továbbiakban konstansként szerepel a programban, amit pointerként fel lehet használni, mert a tömb nulladik elemére mutat. Hogy felhasználod-e, vagy ugyanezt a kezdőcímet egy másik pointerbe teszed, és a továbbiakban azt használod, az már rajtad áll, teljesen mindegy (a generált kódot nem néztem, ott lehet némi eltérés, de biztos nem nagy). Igazából nem értem, hogy miért van ez így kihangsúlyozva a leírásban...

Akkor valószínűleg ezt nem értetted. Amikor azt látod, hogy char * ptr, az nem az jelenti, hogy a cím az előjeles, hanem hogy az azon a címen levő adat előjelesként kezelendő, amikor azt valahol felhasználjuk pl. egy feltételes ugrásnál.

Igen, tulajdonkepp ezt csinalta potyo is, csak o nem hozott letre sectiont a linker scriptben.

A masik ahhoz amit potyo mondott, hogy C-ben minden pointer. Mikor egy tombod van, akkor is tulajdonkepp egy pointered van, ezert is lehet keverni azokat. Ha megfigyeled a peldat amit irtal, abban a char* buf_ptr -t utana siman buf_ptr[index] -kent hasznalja. Elmeletileg a char *buf_ptr = &buffer[0] helyett is lehetett volna char *buf_ptr = buffer -t irni.

A pointer tipusa amugy azt is megmondja mikent kell szamolni vele (pointer aritmetika). Tehat a buf_ptr+5 (avagy buf_ptr[5]) -nel neki tudnia kell 8, 16 vagy 32 bites (vagy akar strukturanal ennel is hosszabb) szamot kell az eredeti memoria cimhez hozza adnia.

Igen, köszi, már vágom. Csak a típust mutatja, amire mutat azét...(jajj! )
Mindenesetre átalakítottam, és most már az sem működik ami eddig! Gyúrom tovább...

Üdv mindenkinek!
Még mindig ezzel a fránya 627 tel szívok.
Megpróbáltam magasabb feszen törölni, írni de nem lehet így se. Pic nél nincs valami olyasmi mint teljes formázás?

Dehogynem, mar egyszer leirtam, hogy a "bulk erase" az... hogy hogy forditottak ezt magyarra sajnos nem tudom, en nem hasznalok magyar nyelvu dolgokat, mert sokkal kevesebb magyarazatot talalni magyarul a neten...

Ha a bulk erease után is csak rosszul detektálja, akkor szerintem ott a core sérült. Nem hiszem, hogy lehet kezdeni vele bármit is, maximum kitűzheted az ingedre dekorációnak a chipet, ha nem akarod kidobni

Gondolkodtam Thowra, ugy tudnad torolni, hogy ovatosan az oldalcsipovel keresztbe rafogsz, es egy enyhe nyomassal picit tartod, majd folyamatosan novekvo nyomast gyakorolsz ra mig kette nem valik a muanyag tokja es lathatova nem valik a szilikon lapkaja.

Ezekutan az egeszet beteszed a kukaba es eloveszed a masikat amit epp most vettel a boltban... Es mikozben ezzel az ujjal dolgozol foldeld le magad nehogy a statikus feltoltodes tonkre tegye a chipedet.

Ti milyen földelést használtok? Nálam a virágboltban vett muskátliföld vállt be a legjobban!
Egyébként ha van egy fémfelület, amit meg lehet fogni, és a PC földelt(!) fémrészéhez is van köze, akkor annak megtapizása már elegendő lehet... Ilyen pl. az USB hosszabbító dugó vége...

Üdv!
A bulk erese vel az a bajom, hogy nem tudom pontosan hogy és milyen progival kell elkövetni
Ami a füldelést illeti azt használok.
A második hsz ed teccett
Szóval mi is ez a bulk erase? és hogy is kell?

Abban nem bíznék, annyi árnyékolás nélküli usb kábelt láttam már...

Megmondom őszintén, én otthon általában semmit. Viszont utálom a műszálas cuccokat, úgyhogy nem szoktam "csattogni". Ráadásul egy jó fél éve, amióta a PIC-es pákámat megépítettem, azóta azzal dolgozok, és annak a pákának a teste földelt (a PC táp, amiről megy, az is földelt, a páka háza össze van kötve a táp házával).

Sziasztok!
Abban szeretném a segítségeteket kérni, hogy segítsetek elindítani a pic programozás rögös útján!
Szóval el tudnátok nekem magyarázni egyszerűen hogy hogyan kell a hs oszcillátort bekötni,az égető rajzát elmagyarázni (amit a pices cikkben taglaltak)
melyik jelölés mit jelent,ilyen nagyon alap dolgok!
A kedves segítégeteket nagyon köszönöm!!!

Találkozott már valaki olyan problémával , hogy az égető (PicKit2) felismeri a pic-et de nem tudja égetni? (16f877) Törölni tudom, törlődik rendesen. Bármit próbálok bele írni hibát ír ki. (mindenhol 0000h, 0001h, 0002h, 0005h, vagy 200X h értékeket olvas vissza) Meghalt volna a pic ben a flash memória?

Minden mással megy az égető (másik 877 el is).