Filozok egy olyanon, hogy több flash kártyát rápakolni usb meghajtásra, és ott jó tudni, hogy valami 100 mA-t eszik-e, vagy csak 10-et. Ha tényleg lenyel 100-at, hagyom is a fenébe.

De amúgy kicsit furcsa. 3.3v-on a 100 mA már 1/3 watt azon a picike vacakon. Szét kellene égnie a fenébe egy fél órás nyüstölés után, de amikor kiveszek egy 16 gigás microsd kártyát a laptopomból egyhuzamos teleírás után (kb 35-40 percig tolja), az "hideg", pedig benne volt a nagyobb SD műanyag foglalatban, nem tudhatott az olyan gyorsan hűlni.

Az sqi csak azért vetődött fel, mert ha azzal kapcsoltatok flash kártyát, akkor tuti nagy sebességgel kezeltétek. Nyilván a kártya kevesebbet eszik, ha másodpercenként 1-2 szektort bizergálsz, mintha másodpercenként sokezrével írod / olvasod.

Kicsit off, de szeritnem attól is függ a fogyasztás, hogy milyen flash van benne (a gyorsabbak jobban melegednek, mily meglepő)). Van egy 16G-s és egy 32G-s pendriveom, a 32-es melegszik a 16-os nem, a 16-ost 5Megával lehet írni, a 32-est 16Megával...

Van egy rossz hírem SQI ügyben. Lehet, hogy nem fog menni SD 4 bites protokollal. De még keresgélek...

Miért nem fog menni?

Esetleg nem tudsz valahol, egy jó library-t a PIC32MZ I2C buszhoz, hogy ne kelljen teljesen az elejéről megírnom?

Mert nem tudom, hogy lehet-e címzés nélkül használni, nem értem még az adatlapot. Itt minden adatvonal kétirányú, azaz azt is meg kell mondani az SQI-nek, hogy adásra, vagy vételre váltson. Az SD protokoll se teljesen tiszta még. Ilyet nem csináltam még és ami problémás, hogy nem is találok erről semmilyen infót, vagy példát a neten...

Sajna nem, de az MX-hez készült is jónak kéne lenni, az meg talán van a Harmony-ban (de lehet, hogy MZ-hez is van, mintha láttam volna). Ha találok valamit, jelzem (igaz, most elfoglalt vagyok, mert az MZ-hez XC32 kell, ami nekem eddig nem volt fenn, nem ismerem és küzdök vele...)

Én ugyan csak futólag néztem át de úgy láttam, hogy menne a dolog.

Harmony az fel van telepítve. Ezzel projektet lehet létrehozni, vagy valahol megtalálom a h és c fájlokat?
Apps/peripheral/i2c könyvtárban vagy merre keressem?

Ahogy igy atfutottam az SQI leirasat, gyanitom, hogy ezzel SD kartyat 4 bites modban nem lehet hasznalni. Ott ugyanis van meg egy ketiranyu CMD jel is, amit ez a modul nem allit elo. Marpedig az SD-nel az egy igen fontos jel, mert ezen keresztul mennek a parancsok, es ezen is jonnek vissza a valaszok. A 4 DAT labon csak az adat maga jon-megy. Egesz mas protokoll az SD, mint a soros FLASH-ek.

Nézegetem... Úgy nem menne, hogy beállítok egy tetszőleges lábat Command/Response vezérlésére és a modult akkor használom adat továbbításra, vagy vételre, ha már beállítottam a vonalak irányát? A PMP is így megy... Ami homály, az maga az SQI belső felépítése és a sok regiszterét még nem volt időm átrágni...

Nem néztem tüzetesen, de láttam a perifériákat. Készíts egy harmony projectet és állítsd be az I2C-t. Biztosan meg lehet találni az ide vonatkozó rutinokat, bár amit tudnak ezek művelni, az elég kemény!

Igen, azért kérdeztem!

Azt a cmd vonalat hogyan használja az sd protocol? Amit neten fellelni tudtam, mind csak egyszerűsített sd leírások, és ott semmi időzítési adat vagy leírás nincs a cmd használatáról. Az a cmd vonal jellegében igényli, hogy az órajellel együtt fusson 1 bit / clock pulse átviteli sebességgel, vagy csak valami jelző bit arra, hogy a data0..3 vonalak mire vannak aktuálisan használva?

Nézd meg ebben: SDSpec.pdf
A cmd lábat a leírásban Command/Response funkcióval jelölik. Egyszerűen az adavonalak irányát állítja be. Minden bizonnyal a beállítás után szükséges valamennyi idő az adatforgalom megkezdése előtt, amit kísérletezéssel is ki lehet találni, de valami 6 és 14nsec körüli értékeket olvastam a CLK-hoz képest. De nem a vonalak beállására való várakozás fog lassúságot okozni, mert az irányváltások aránya időben sokkal kisebb, mint az adatoké, feltéve, ha nem egyesével összevissza címekről olvasol.

Ezt mibol gondolod? Azon megy a parancs es azon jon vissza a valasz. Ott vanbenne abban a leirasban, amit linkeltel. 4-1 fejezet.

A CMD/RESP egy ketiranyu adatvezetek, a CLK-val egyutt kell hasznalni, mint a DAT labakat is. Ez mar a multimedia kartyaknal is igy volt (MC), csak azoknal 1 DAT volt, nem 4. Ezen kuldod be a parancsokat a kartyanak es itt kuldi vissza a kartya az olvasott regiszterk erteket, itt kuldi vissza a hibakodokat. Sosem gondolkodtam azon, hogy lehet-e software-bol hasznalni, mert ertelmet veszit az egesz dolog, mert lassu lesz. Akkor mar inkabb SPI-n hasznalnam az SD kartyat.

Bevallom, így tűnt logikusnak, de hogy írod, már kezd világosodni.
Azt mondod szoftverből kezelni a CMD-t lassú. Szerintem olyan kis szeletet tesz ki ez a rész, hogy elhanyagolható. Jelen esetben az is javíthat az időkön, hogy 200MHz-es PIC-el használunk.

Az viszont macerás lehet, hogy ugyanazt az órajelet kell használnia a szoftveres és a SQI vonalnak is (ha jól értem). Talán az se túl időigényes, hogy át kell konfigurálni a lábat. Az lehet esetleg probléma, ha a válasz vétele közben már adat is jönne ugyanazon órajelen. Nem sokat értettem még meg az adatlapokból időre van szükség, ami kevés van...

Igazad lesz, ezt nem lehet SQI-vel, ahogy az elején megéreztem, most már szinte biztos vagyok, hogy nem érdemes, illetve nem lehet összefésülni a kettőt. Az adatlap szerint, ha jól értelmeztem, az adatok már akkor elindulnak, amikor még a CMD vonalon javában jön vissza a válasz. Nem találtam még olyan szinkron pontot, ahol át lehetne váltani SQI-re, majd vissza. Szomorú vagyok...

Esetleg, ha láttok rést a falon szívesen venném! Arra gondolok, hogy szoftveresen kiadom a CMD-re a parancsokat, majd átváltok SQI-re és küldöm, vagy fogadom az adatokat, utána vissza CMD-re és lezárom a kommunkációt. Azt megtenném úgy is, hogy esetleg egy-egy response elvész. Nem tudom...
A gondom az, hogy az SPI-vel elérhető 3,125 MB/sec nagyon karcsú egy TFT-hez.

Sajnálatos eset, de szerintem sem fog menni. Ránéztem a doksira én is - több szem többet lát alapon - és ezt találtam "A command is transferred serially on the CMD line". Nem csak szimpla jelző bitnek tűnik nekem.

Azt se felejtsd el, hogy az sd reakció idői nagyon viccesek tudnak lenni. Néha jön azonnal a cucc, néha meg 100 millisec (!) késleltetés is ott van még egy class 10 kártya esetében is. Amikor a háttérben a wear leveling vacakol valamit, azt pont visszaolvasásnál teszi, nem írásnál. Az sd kártyákat nem real-time eszköznek találták ki. Ahol használják, mindenütt memória buffereken keresztül kezelik. Egy pic esetében jellemzően nincsen annyi memória, ami multimédiás adatok teljesítmény alapú kezeléséhez elég tudna lenni buffereléshez. (A pic 32mz/da családban éppen olyasmit ígértek, hogy 32 megabyte ddr ram beépítve a pic tokjába, azt azért is hajtottam annyira, hogy mi a rák van vele, de csak annyi derült ki, hogy bármi is van vele, az ebben az évben még nem fog megtörténni.)

Ha bármilyen vékony szalmaszálba hajlandó vagy belekapaszkodni, van egy 32mz-n nem kevés spi port. Használhatsz több kártyát párhuzamos üzemben, és úgy össze lehet adni az spi-k sebességét. De akkor nem egy nagy, hanem sok kicsi kártyára lesz szükséged, és ott meg elektronikai oldalon fog furcsán kinézni a történet.

Köszi, hogy foglalkoztál vele! Még egy lehetőség lenne, valami interface.

Wezuv!

Beszéltünk anno az RA7785-ös controller-ről, hogy lassabb, mint az SSD. Most kipróbáltam és így van, grafikai megjelenítésekben lassabb. DMA nélkül 16 bites PMP-vel, a WAIT lábat poll-ozva egy 640x480-as képet lemértem a timer-el és kereken 3600ms alatt rajzol fel, ez 3s.

Viszont a beépített grafikai funkciói nagyon jók. Úgy láttam az ssd-ben nincsenek ilyenek. Vonal rajzoláshoz a kezdő és vég koordinátákat kell megadnom, háromszöghöz is 3 koordinátát, tud még ellipszist, kört, négyzetet és lekerekített sarkú négyzetet rajzolni, itt a rádiuszt meg lehet adni.
Ezek a grafikai elemek nagyon gyorsak.

Szerintem ez a sebesség indokolatlanul alacsony. A két vezérlő között, max kétszeres a különbség, ami azt jelenti, hogy ami nálam 2tized (MX-el!), az nálad 4 tized. Nem 3,6sec! De javaslom menjünk át az LCD-be!

A pic32mz/ec doksi szerint tud az mz ebi-t, meg sqi-t. Lévén az ec a legújabb család, egyenlőre nincsen pic-nek sd supportja hardveresen. Az spi a leggyorsabb lehetőség.

Ami más lehetőség lenne - természetesen van - azzal még több a macera, mint a sok flash kártyás megoldással. Kell egy fpga - cpld-ben simán csak nincs elég logikai erőforrás ilyesmihez - és felhasználni azt az sd kártyával kommunikálni. Szerintem sd-hez van support xilinxéknél. Az fpga-hoz a kliens perifériát persze meg kell írni, kiképezni a kommunikációhoz a regisztereket, viszont lévén az arra van kitalálva, használni lehet tetszés szerinti pic perifériát az átvitelhez. Ami a nehéz része ennek az útnak, hogy az fpga-k többsége bga tokos, nem amatőr környezetbe való azt forrasztgatni. Még a tqg-144 lábas tokot ha egyáltalán lehetséges is felforrasztani (0.5 mm-es lábtávolság), kell hozzá egy biztos kéz, és ha mégis elrontod, temérdek sok ónpocsékolás (+ célirányos ic kiforrasztó fej) azt utána levenni a panelről úgy, hogy nem téped fel a nyákot. Ha üzleti célra készülne egy ilyesmi, és megfinanszírozható előregyártott hardver, akkor érdemes ilyesmivel pepecselni, egyébként veszett ügy.

Elvileg (de ezt megint csak emlékeim szerint írom), már van SQI-s flash (utána kell nézzek, kapható-e). Ezzel lehetne a sebességet és a tárhelyet TFT (800x480) szintre emelni, hogy pár kép beférjen legalább. Létezik SDIO konverter, ami 16bites buszra illeszt, de nem kapható, még a farnellnél sem. A xilinx vonalat hanyagolom, belefáradtam...
Mekkora gáz, hogy bárhol kapsz egy SDHC olvasót gyök kettőért, de a benne lévő IC-t nem lehet megkapni. Ma szétkapom az otthonit, megnézem mi van benne!

Sajnos tényleg az megy. Lassan egybeintegrálják a flasht is meg az usb asicot is, hogy a panelen csak egy fekete pacát látsz, amiből csak annyi kivezetés van, ami közvetlenül az usb csatlakozóhoz megy, és az egészet fillérekért kapod meg. De annak az a kisbetűs tartozéka, hogy csak úgy és csak arra a célra használhatod fel, amihez és ahogyan azt kitalálták. Esetleg áttérhetsz valami android boardra. Androidéknál van flash is, meg színes kijelző is. Szólok előre, kisbetűs rész ott is lesz, de az egyéni preferencia kérdése.

Írtam a színes LCD-be.

Van ilyenem, nem játszik hardver közeliben, nekem az is kell, ezért PIC32MZ. Szép az élet...
Találtam SDIO101A-t, de nem kapni sehol, és BGA, de még a szolidabb. Alibabán mintha lenne, de nem írnak semmit, csak hogy 10dolcsi. Látatlanba nem merném, meg egyébként se jó bizonytalan forrásra építeni.

Valamiért a PIC32MZ2048EFH100-omon nem jól jár az egyik Timer. 1000x leellenőriztem, kiszámoltam mindent és jónak tűnik. De most lemértem 1 percet és valójában kb. 1,5 perc.

Ezek a config bitek:


Ez pedig a timer beállításai:

A megszakítás:


Ahogy teszteltem:

A start felirat megjelenésekor, vagyis táp ráadása után elindítottam a stoppert, majd a stop felirat kb. 1 perc 30 másodperc múlva jelent meg.

Ha az a gyanú, hogy alapvető beállításokkal van a baj, nem kellene túl sok tényezőt belekeverni a történetbe. MX-nél van a cpu0,9 regiszter (32 bites), ami fixen a rendszer órajel felével számolja az ütemeket. Elvileg MZ alatt is megvan.

Kinullázni:


Értéket kiolvasni:


Csinálni egy ciklust, ami csak arra vár, mikor éri el mondjuk a 100 milliót, és felvillant egy ledet, vagy kioltja. Ha annak alapján kb stimmel az órajel időre (beállítani a villogást mondjuk 1 sec-re), akkor legalább az órajel rendben van. Ha nem, még az órajel beállítások sem stimmelnek, kár addig a timert hibáztatni.

Én meg szívok itt az MX után. Próbálom átültetni a kódokat, amik jól működnek, ekkor derül ki, hogy az MZ-re még nem implementálták a periféria headereket (nem működnek a helpben leírt dolgok, pl. opentimer2 stb.). Nagyon úgy tűnik nem is fogják, mert a Harmony van helyette, ami egy nagy kalap katyvasz. Végre hozzászoktam a kényelemhez, most mindent lehet regiszterenként. Örvendek.

Tehát a végtelenciklus előtt kinullázom, a végtelenciklusban folyamatosan figyelem, hogy nagyobb-e mint 100 millió?
A 100 millió az 1 másodperc ugye?
Xc32 alatt is működnek ezek a függvények amiket írtál?