A dolog javulni látszik, a programban kicsit piszkálni kellett, de nem ettől javult meg.
5V-os PIC-ről hajtom az SD kártyát, úgy ahogy ezt mindenhol javasolják, a kimeneteken ( CLK, MOSI) egy 1,8K ás 3,3K osztóval. Nos ez az ami nem működik.
A program megpiszkálása után az init már lefutott, de az írás katasztrofális volt... az első pár byte többnyire jó volt, aztán megzavarodott és szemetet írt be, bár néha sikerült neki eltalálni.
Fél napos küzdés után azt mondtam lesz ami lesz, legfeljebb megölöm a kártyát, a MOSI-ról levettem az osztó 3,3K-s ellenállását, így a MOSI egy 1,8K-n keresztül csatlakozik a kártya SI-re, azaz nincs meg a feszültségosztó.
Lőn csoda, 100% az írás - olvasás.
Roppant hálás lennék ha valaki eltudná ezt nekem magyarázni!
Amíg a hardver nem 100% megbízható, nem akarok továbbmenni a FAT felé.
A másik dolog amit nem értek, hogy a kártyát hiába nézem winhex-el, azon ugyan semmit nem lát, pedig a PIC visszaolvassa... de honnan??

Én az egészet 3,3V-ról hajtom, minek a szintillesztéssel külön nyűglődni? Az 5V-os picek adatlapja mindig MAX 5V-ról beszél, nem kell neki pont annyi. Tökéletesen stabil a 3,3V-ról is. Ha a PIC eleinte 5V-ról ment, és az SD 3,3V magas szintekkel akart neki üzenni, a pic lehet, hogy nem is érzékelte magasnak azt a szintet. (Nekem egyébként ez vált be eddig kétirányú szintillesztéshez)
Amit ide kiraktam, nekem kitartóan működik. Legyen teljesen üres a kártya (minden 00), formázd a ccs-féle formattal, és utána mennie kell. Előbb próbáltam egy újabb 1GB kártyával is, ott ugyanez keltette életre.

Hali
Ha jol megnezed a SDI labat, az egy ST bemenet. A ST-s bemenetek tulajdonsaga, hogy a Vih = 0.8xVDD, ami 5 volt tapnal pontosan 4 volt. Tehat csak az ennel magasabb feszre fogja mondani, hogy "H" van a bemeneten. Erre olyan megoldast lattam, hogy a bemeneten van egy feszultsegoszto, ami beallit 4,1 voltot, es az kartya kimenetevel sorba van kotve egy dioda.SD card interface.

Nagyvonalakban ugyan ezt csináltam ez nem ment csak ha levettem az R9-et, azaz az SDO!! osztót. Az SDI símán rá van kötve a PIC bemenetére, azzal nincs baj (pillanatnyilag), bár ez a diódás megoldás megfontolandó.
A bemenetnek elégnek tűnik a kártya kimenete, mivel működik. Ezt más fórumokon is taglalták hogy elméletileg nem kéne hogy működjön, de úgy látszik ezt a kontrollerek nem olvasták
szkrep:
Itt pont ezt taglaltuk ki. Bizonyára szerencséd van ha stabilan megy a PIC-ed 3,3V-ról. Valószínű fajtája válogatja, nekem a 18F4620 nem jött be.

Szoval nem tudom hogy nalad miert nem megy, de eddig amivel talakoztam, altalaban mind tudta a speckot, amit leirtak. Persze vannak furcsa "megmagyarazhatatlan" jelensegek, amikre kesobb rajon az ember hogy "de nagy barom voltam". Itt gondolok a tap stabilitasara, szuresere, rossz, hasznalt alkatreszek hibaira, lebego portlabakra. Sokszor meg problema a "keksz" (probapanel) alkalmazasa. Rossz kontaktok, hosszu vezetekek, amik osszeszednek minden zajt. Na es melle meg ugye a tapasztalatlansag a programozasban. Na ne vedd magadra, de sokszor ilyen egyszeru problemak miatt nem tud elore haladni a kedves ifju kollega. Amugy en hasznalok PIC-eket 2 ceruzaelemrol, ami honapokat is megy 2 nyuszis elemmel minden problema nelkul.

Nem szerencse, de valóban nem figyeltem ilyesmire soha:
Supply Voltage (18F4550)
2.0 — 5.5 V EC, HS, XT and Internal Oscillator modes
3.0 — 5.5 V HSPLL, XTPLL, ECPIO and ECPLL Oscillator modes
Szóval 0,3V-al fölötte vagyok, pont jó.
A 18F4620 adatlapban tényleg az van(326.o). hogy min 4,2V kell, a 18LF4620 miatt írhattak 2-5V működést a honlapon -pedig az végülis egy másik típus ebből a szempontból, nem mindegy melyiket veszed...

Sajnos nekem marad az 5V-os (18F6722), mert pár periféria ami rá lesz akasztva az csak 4,5 - 5,5V tartományban működik, és az analóg és digit kimenetei is ezeket a szinteket adják, így mindenképpen kell valami szintillesztést csinálnom, azt hiszem a kártya illesztése jár a legkisebb fájdalommal, de már látom hogy ez sem egyszerű.

Van itt egy könyv, ami kifejezetten PIC18-SD kártya illesztésről szól, s ebben a PIC18F8722-höz 2,2 kohm/3,3 kohmos osztókkal valósítja meg a szintillesztést. (A linkek megjelenéséhez valószínűleg regisztrálni kell)

Köszi! Jónak ígérkezik (ha sikerül letölteni, még nem própáltam mert regisztrálni kell, azt majd egy másik gépről, valamiért a .ru oldalakkal bizalmatlan vagyok)
Az a gyanúm hogy azzal tovább rontanék a helyzetemen. Ha az 1,8K/3,3K osztó már nem volt neki elég szerintem a 2,2K/3,3K tovább rontana a helyzeten. Most egy 1K/3,3K -val megy 16F877-el is és 18F4550-el is (ezek voltak itthon).
Vilmosd belinkelt DO->MISO megoldása annyira megtetszett, hogy hirtelen ki is próbáltam, kiválóan működik, később még 2 diódával is kipróbálom, kb. az lenne a tökéletes. Nagy ötlet! Köszönöm, lassan jöhet a FAT.

Megértem, csak annyit szeretnék megjegyezni, hogy ez .nu, nem pedig .ru. Hogy ez jobb, vagy rosszabb azt nem tudom...

Valaki szánjon meg egy normális DCF77 dekódoló linkkel... Ez tettszene: Bővebben: Link de ha 20MHz-ről üzemeltetem, a (zero drift!) RTC lassabban ketyeg mint 1mp. Körülbelül 1,5...2mpként lép. A DCF része meg nem szinkronizál. Megpróbáltam 32MHz-ről (természetesen a konfigba beállítottam), és akkor meg 2-3-mat is lépett 1mp alatt. Annyit változtattam, hogy 18F2423-at használok és RB0 a bemenet.
A proteus szimuláció is pontosan ezt mutatta (,hogy gyorsabb vagy lassabb és nem szinkronizál). Vajon mit néztem be?

Idézet:
„Megértem, csak annyit szeretnék megjegyezni, hogy ez .nu, nem pedig .ru. Hogy ez jobb, vagy rosszabb azt nem tudom...”

.ru -ban jobal tobb a tamado ldalak szama -- Oroszoknal eleg sok az online bunozo sajnos.

Elérkezett a gyönyörű pillanat, belekezdtem a FAT-ba, természetesen nem működik.
A dolog pikantériája, hogy a kártyát leformázom a PIC-el, kiválóan működik, ír olvas kekszet megrágja de...
Az hogy a PC nem látja, az gond, - bár a végcél az lenne hogy tudjam PIC-el is és a PC-vel is írni olvasni - de hogy a winhex sem lát belőle semmit az már kicsit aggaszt. Fél napom és egy éjszakám ment rá, de ötletem sincs. A PIC látja a FAT-ot, látja a file-okat, tudja írni olvasni, kiveszem - berakom ott van és működik, de a winhex semmit nem lát az egészből.
A csatolt képeken a 0. szektor van amit a PIC kiolvas (rövid mert csak az első 0 byte-ig írja ki) a másik a winhex amivel ha rákeresek sem találom sehol a kártyán, csupa 00 byte.
Valamit nem jól csinálok, vagy el vagyok átkozva???

Particios tabla (Master Boot Record avagy MBR) van azon a kartyan?

Agyvérzés van.... A 4.110-es fordítót lecseréltem 4.104 re és működni látszik..

Valami rafinált oknál fogva esze ágában nem volt írni a 0. szektort....
Most ott tartok, hogy ha a PIC-el formázom a PC kiválóan olvassa, de ha a PC ír bele az széttrancsírozza. Most jön a BUGFIX

szkrep:
Neked is és mindenkinek ajánlom a BUGFIX-et! Csodára képes!
A kártyát lehet formázni PC-n is és a PIC-el is, mindegy neki, írják-olvassák egymás file-jait.
A file-nevek értelmezésével még vannak problémák, pl az a.txt -t a PIC atxt -nek látja. Megpróbálom megkeresni, ha sikerült közkincsé teszem.

Meg is van a bugfix bugfixe a fat.c-ben

Ezzel a kis módosítással már teljesen jónak ígérkezik, eddig 100% PC kompatibilis, bár még tesztelgetem.
Használjátok egészséggel!

Ez igy biztosan nem jo, hiszen az sname[ -1 ] -et cimzed ha j == 0 !

Amugy szerintem az az else ag teljesen felesleges! Ott valami mas problema lessz... Ez a kod annyit csinal csupan (leszamitva az else agadat), hogy a directory tablaban tarolt 8+3 karakterbol eloallitja a "8.3" formatumu nevet amit kesobb meg tudsz jeleniteni --merthogy a directory tablaban a nev fix 8 karakteres mezoben van, a kiterjesztes pedig fix 3 karakteresben kozvetlen egymas utan, nincs pont, es a filenev ill kiterjesztes nem tartalmazhat szokozt, igy ha a file nev pl rovidebb, mint 8 karakter, akkor a kianyzo reszek szokozokkel vannak feltoltve.

Tehat az algoritmus kihagyja a szokozoket, es beilleszt egy pottyot a kiterjesztes elott a karakter lancba. Ha pedig nem volt kiterjesztes, azaz a legutolso karakter a potty, akkor azt onnan kiszedi, mert nem szep, ha az ott van...

Ennyi... Mi volt a szandekod azzal az else aggal?

:no:
Szerinted a j mikor lesz 0? Nem hiszem hogy túl gyakoriak lennének a FAT-ban a név nélküli file-ok amiknek csak kiterjesztésük van. Lehet hogy hihetetlen, de én is tudom mit csinál.

Mindössze annyi hogy ha a fileneveket helyesen jelenítse meg, mivel eddig ezt nem tette ld.(#918272)
Természetesen nem kötelező senkinek megvalósítani, de ha esetleg valakit zavar hogy a filenevek nem jók annak jól jöhet.
Engen zavart hogy akár a PC-vel akár a PIC el készült a file a nevét hibásan kezelte.

Igen erre már én is ráakadtam a ccs fórumon. Nekem a filenevek mindig jól jelentek meg, legalábbis nem vettem észre soha ilyen gondot. Ez a bugfix megbízhatóbbá tette a működést, de ha PC-n formázom, a pic olyan helyre ír rajta, hogy csak ő látja. Én kitartok a bugfix utáni format()-nál, azután teljes a kompatibilitás.
Milyen oprendszer van amúgy a gépeden? Elvileg nem szabadna különbségnek lennie a formázásban, de kezdem azt hinni, hogy a Windows7 máshogy csinál valamit...

Eddig csak XP-vel, és PDA-val és a f néztem, azzokkal teljesen jó. A hiba akkor jelentkezik, ha egy karakteres filenevet adsz pl 1.dat, ilyenkor a pic 1dat-ként kezeli.

Neked nem abbol kellene kiindulnod, hogy szerinted mi a gyakori es mi nem, mert pontosan az ilyen hozzaallas vezet a sok-sok Windows-os es Adobe-s vulnerability-khez, aztan a felhasznalok csodalkoznak mi a fenetol fertozodott meg a szamitogepuk mikor ok csak az internetet bongeszik. Nem lehet a felhasznalok butasagabol kiindulni, sot abbol sem, hogy egy masik programozo (vagy akar Te) nem vet el hibat ami nem general olyan inputot amitol a Te szoftvered fejre fog allni. De biztonsagos szoftver fejlesztesebe most ne menjunk bele, mert az nagyon off lenne.

(nezdd meg a kepet)

Erőszakkal a lovat is meg lehet ...ni, de normál használat mellett ILYEN NINCS, én pedig azt a kevéske tudásomat amit sikerült hobbistaként megszerezni, nem kártevők írására fordítom.
Ami képet küldtél természetesen én is tudom produkálni, de értelme épp semmi, a FAT ilyet nem enged (a hosszú filenevekt most hagyjuk). Esetleg ha a FAT kiherélése után megpróbálsz hozzáférni a csodafileokhoz kevés esélyt adnék a sikerednek.
Elfogadom hogy van más megoldás, minden problémára van több megoldás, de Te is hidd el, hogy nem azért csináltam hogy a fórumozókkal kibabráljak, hanem azért mert hibásan működött, és az általad feleslegesnek és hibásnak ítélt módosítás után a hiba többé nem jelentkezett.
Természetesen elfogadom az álláspontodat, csak kissé erőltetettnek találom a felhozott indokokat, mivel itt egy PIC-ről van szó.

En nem felteteleztem direktben szeretnel kibabrani masokkal, csaupan felhivtam a figyelmedet egy hianyossagra. De nekem mindegy, maradhat igy is felolem.

Sziasztok !
Látom itt kicsit komolyabb témákról van szó mint az enyém, ezért is gondolom azt hogy tudnátok nekem segíteni vagy tanácsot adni a kezdő problémámban!
Az SPI kommunikációval próbálkozom az AN966 alapján de nem túl sikeresen! A gond az hogy a szimulátorban (Proteus) nem működik a dolog. A PIC SDO kimenetén szépen megjelennek a jelek de semmit nem változtat a memóriában. A szimulátort lepróbáltam az AN966-os ASM-el és ott jól működik de amit én írok CCS-ben az nem. Megfigyeltem hogy a mintapéldában a küldés után csak akkor megy tovább a program ha az SSPBUF 0. bitje azaz a BF bit 1-be vált, a CCS progiban pedig a 0x03-as címen figyeli a 0. bitet , de az a STATUS regiszter C bitje !
Vajon a fordító rossz vagy én szúrok el valamit?

Sziasztok!

Nincs valakinek Nokia 3310 lcd -hez magyar ékezetes karakterkészlet?
Köszönöm.

Csatolnád a proteus file-t is? Másik fordítóval próbáltad már?
Már volt rá precedens hogy a CCS hibázott...

Köszi WHALAKY, hogy foglalkozol a problémámmal , már letettem róla hogy bárki is segíteni fog...
Nem próbáltam másik fordítóval csak más verziójú CCS-el, de ugyanaz a helyzet. Csatolom a Proteus fájlokat remélem segít valamit. Egyébként Neked van működő SPI-s kódod?

Szia!

A csatolt módosított program Proteus-ban kapcsolja az OK LED-et.

Üdv!