Én tuti a linuxos drivert nézném meg, ha valaminek a működéséről nincs rendes doksi, de van jól működő driver linuxra.

Linkeket köszönöm, lementettem az összes oldalt saját gépre is. Már előre félek, hogy ezen mind keresztül kell rágnom magam

A hex editor külön öröm volt. Én csak valami Hex Work version 7 akármennyit találtam, ami nem free, és regisztrációs korlátokért pampog folyamat.

Azok a linuxos driverek néha hasznos segítség, de inkább csak részlet kérdések vizsgálatához, és nem átfogó doksiként. Az átfogó doksit szerintem a világon semmi sem pótolja. Ha néha kódba turkálok is bele, az egyetlen, amit teszek, hogy normális doksit gyártok belőle magamnak, és utána abból boldogulok.

Ha gondolod leírok pár alap információt, hogy legyen valami kiindulási pontod, arra meg már építhetsz és könnyebb is lenne megérteni a részleteket...

Köszönöm, de kell valami szórakozás nekem is

Az sd része miatt már nem különösebben aggódom, és a filesystemmel is el fogok boldogulni. Ennyi doksi + a disk editor bőven elég lesz.

Ha azzal a 18f4550-el esetleg usb-re kötötted rá a "pen drive"-ot, és turkáltál egy adagnyit az mc usb libjében is, arról néhány alapvető lib szerkezeti felvilágosításnak örülnék. De lévén az meg itt offtopic lenne, azt akkor is inkább priváte, vagy egy másik topicban.

A linkelt HxD editort beizzítottam egy SD kártyára windows 7 alatt, és belenéztem vele egy SD kártyán létrehozott partícióba.

Az "üres" szektorok nem 0xFF-ekkel voltak feltöltve, hanem 0x00-val, amitől nekem kicsit égnek áll a hajam. Egykori ismereteim szerint egy törölt flash 0xFF-ekkel van feltöltve. Mindez csak azért érdekes, mert amíg 0xFF-ekkel van tele, addig egy új szektor felírása nem feltétlen jelenti a teljes blokk (átlag 128kbyte vagy 256kbyte) újbóli törlését, a régi adatok visszavezetését, és az új szektor felírását, hanem simán csak be lehet írni az új szektort a helyére. Ha viszont eleve "kiégetett" byte-okkal van tele minden, minden alkalommal kelleni fog egy újbóli törlés, ami kb egészen biztosan szét fogja nyírni a flash-t egy olyan file műveletnél, mint log file írása kicsike szöveg darabokkal.

Jelenleg azon filozom, hogy csak rémeket látok, vagy tényleg a jelen kori flash rendszerek lennének egészen őrültek?

Sziasztok!

Nem PIC, de SD.
Van egy Discovery nevű fejlesztő eszköz STM procikhoz. Ennek az egyik moduljának a kapcsolási rajzát csatolom. Az 5. oldalon van a mico SD kártya bekötése. Tök jól működik meg minden, de szerintetek mi a létjogosultsága a soros 22 ohmos ellenállásoknak az adat vonalakon? Kellenek azok oda? Elég sok helyet elvesznek egy panelen, ahol a minimalizálás a cél.
Ugyanez a kérdésem érvényes egyúttal a 47k-s felhúzó ellenállásokra is, bár az gondolom az open-drain bemenetek miatt van.

Köszönöm!
Ádám

Röviden: kellenek, különben nem rakták volna oda. A hosszú vezeték miatti túllövések csökkentése miatt.
A 47k-k azért kellenek, hogy amikor éppen nem aktív a kártya vagy a CPU, akkor se lógjanak a bemenetek a levegőben.

Értem.
Mi számít hosszú vezetéknek amúgy? Ha van egy panel ami mindkét irányban 60 mm, akkor azon túl "hosszú" vezetékek nem nagyon vannak.
Mi baj lehet abból, ha lógnak a bemenetek? SD-től egy FET-el elveszem a tápot, amikor nem használom, tehát ott túl nagy gáz nem lehet, SMT meg nem tudom mennyire sértődik meg, ha lóg a bemenete.
Nem az ebet akarom kötni a karóhoz, csak a panelem méretét csökkenteni.
Köszönöm a tanácsaid!

CMOS bemenetet nem illik levegőben lógni hagyni, mert az nem üzemszerű állapota a CMOS bemenetnek, ha mondjuk fél tápra beáll a kóbor elektronok miatt, így a következő komplementer FET pár közül mindkettő egyszerre kinyit.

Az attól is függ, hogy mennyire combos a kimeneti meghajtója az IC-nek. Egy 5-6 centis vezetékre én már tennék.

SMD hálóellenállás. A Lomexnél van pl. CN-43, az 4 ellenállás 3.2x1.6mm-es területen...

Köszönöm a segítséged!
Megfogadom.

Kellene külső tároló kapacitás pic-hez (flash), és áskálódom az adatlapok tömkelegében. Valami nagyon nem tiszta nekem.

Ránézek egy microSD-re, ujjhegynyi valami 4gb kapacitás, valamilyen sebesség, fogyasztás stb, és még egy vezérlő is benne van a tárolók mellett.

Aztán nézek felforrasztható tokos flasheket, és enné meg a fene de ilyen 256mbit / 512mbit környékén véget érnek az adatlapok. Bármi nagyobb kell, azonnal cég referenciát akarnak tőlem, mert hogy addig nem küldenek semmit (gyártók terméklistáit nézegetem).

Ami adatlapok vannak, azokból az derül ki, hogy a kapacitás növekedésével az áramfogyasztás is arányosan növekszik. Már 512mbit környékén egy flash tok dupla annyit megeszik, mint némelyik 8gb-s microsd (twinmos-ok egész alacsony áramon mennek - állítólag). Tokozásra is nagyobb kapacitások felé már növekszik, és 512mbit környékén már eléri a microsd térfogatát.

Szóval hol vannak azok a flash tokok, amiknek a chipjei a microsd kártyákban vannak benne? Mert amiket találok neten adatlapokat, ezek bizony tuti nem azok. Vagy elavult vacakokat reklámoznak mindenütt, vagy azok az adatlapok nem igazak, amik a microSD-ket írják le sebesség / áramfogyasztás / törlési életciklus vonatkozatban.

Ha ásta már bele valaki magát ebbe a szőnyeg alá söpört szeméthalmazba, megköszönnék egy irányadó felvilágosítást, merre is van a rend a káoszban. Plussz hogy mégis milyen eszközzel a legérdemesebb külső nem felejtő ramot felrakni panelre pic-ek mellé.

A következő adatokat kéne tisztázni:
- mekkora kapacitásra van szükséged
- milyen sebességgel akarod elérni (itt nyilván a PIC tudása számottevő limitáció, mert léteznek olyan gyors cuccok, amiket a PIC már nem is tud névleges sebességen megszólítani)
- mi árban a fájdalmasság határa

SPI flashekben (amiket könnyű illeszteni) a 8-16-32MB az értelmes megcélozható méret. Ha ez elég, és nem kell cserélhető legyen, akkor mindenképpen ilyet javasolnék (pl. a chipcad árul Winbond W25xxx modelleket, egy 4MB-os kb. nettó 150 Ft). Ezeket a PIC 1-biten tudja támadni, ami a PIC-ből SPI-n kihozható, azt ezek tudják (mondjuk ilyen ~1.5..2MB/s-ra lehet számítani). Nem érdemes a szükségesnél sokkal nagyobbat berakni, mivel a 'chip erase' funkció sebessége (lassúsága) a teljes méret szerint alakul.
Ha cserélhető kell legyen, akkor SD kártya, azt a PIC szintén SPI-n tudja támadni, kb. hasonló sebessséget lehet velük elérni, a legolcsóbb cucc, amit én láttam, az ilyen 1000-1500 Ft, és 2GB-nál indult.
NAND flash PIC esetén felejtős, az SRAM felületű NOR flash meg a fentiekhez képest drága, és nagyon sok I/O vezetéket megeszik.

Elméletben léteznek olyan chipek, amik az SD kártyával ekvivalens felületet nyújtanak, de ezeket egyfelől macerás (és ezért kicsit drága is) beszerezni, másfelől az előnyüket nem tudnád kihasználni (4/8-bites párhuzamos I/O, esetleg 25MHz feletti órajellel), mivel nincs hozzá hardver támogatás a PIC-ekben.

Ott vannak az SD kártyában. Fogd fel úgy, hogy ez a tokozás! Akár fixen is beforraszthatod a nyomtatott áramköri kártyára, aztán kalap, kabát...

Van feszültségre szűrési lehetőség: a Show All Specs-et be kell jelölni, és máris van feszültségtartomány oszlop.

Bonca

-Kellene nekem egy legalább 2 gigabit (256 megabyte).
-Átlagos adat sebesség mondjuk 100kbit / sec, vagyis 2-3 mbit/sec és lehetnek kieső idők feldolgozás végett késleltetésként. Másodpercenként egy 10kbyte írásnak késleltetésekkel együtt le kellene tudnia zajlani. 3-4 másodpercet tudok átlagolni, lesz hozzá ram. NOR flasheknél 300 mSec egy 4K-s blokk törlése, és az égetés is ugyan annyi. Ott például párhuzamosan több tokra lenne szükségem, hogy a throughputot tartani tudjam, mert annyira lassúak.
-Mindezekért 4-5 ezer hufnál drágább már fájna.
-Forrasztható lenne jobb. Ha elfogadom a mechanikai kockázatot kontakt hibára, akkor egy 32 gigabites microSDHC kártya foglalattal és elé fesz stabbal 3 k huf környéként kijön, de 4.5k huf-ba 64 gigabitet is kapok. (Csakhát a foglalat kontakt. Mondatok, amit akartok, a legprofibb tokoknál sem 100.0% a kontakt. Minimum egy rezgés elnyelő mechanikai környezet kellene mellé, nem rideg fémház. A kontakt nem attól lesz stabil, hogy kemény, mint egy orosz tank, hanem attól, hogy van kidolgozott rezgés csillapítása - ami sehol sincs. Gondoskodhatok arról is magam. Lengő felfogatással szerelni az egész nyákot. Imádni fogom. Vagy megnézhetem, van-e tároló kapacitásra alternatíva. Ezt teszem jelenleg.)
-Suspend áram felvétel ha több 200 uA-nél, vezérelhető fesz stabot fogok elé berakni (az ha jól emlékszem 90 uA) és full lekapcsolom. Például SD kártyák suspendje is akár 500 uA-ig elmegy. Nem szimpik. Bekapcsolás után meg lehet újra kivárni akár egész másodpercet + alapinit.

Winbond tokokból 16-ot fel kellene pakolnom a 2 gigabithez, és soic 16-os tokok darabja 5xx huf + áfa, meg a nyák hely. Nem kicsit agyilag-megzakkant kinézete lesz.


icsernyi:

Okés, elfogadom, hogy az SD tokoknak az a tokozása, csak sajnos abban benne van egy vezérlő is, amivel jelen esetben hátrébb vagyok, mint előrébb, és a pokolba kívánom Kellene belőle a tároló lapka egy másik tokban adatlappal együtt. A microSD-kben benne van azokból vagy 8 darab +vezérlő. Nekem az egyik tároló elég lenne vezérlő nélkül. Az tetszene. Vagy legalább egy közel ekvivalens technológia, mert a winbond és hasonlók nagyon távol vannak tőlük.

Szóval éppen pislogok azon, hogy vannak kínálatban a kőkorszaki katapultok, és azok sem éppen olcsón, meg vannak az űrkorszaki ionágyúk, de a saját rigolyáikkal. Hova lettek a gépfegyverek, meg a rakétavetők? Direkt eltüntették őket a piacról a multik, hogy védjék az SD boltjaikat?


Bonca:

Köszönöm, de a MAPS-ban éppen az - lenne - a jó, hogy globális választékból egy helyen kereshetek mindent, és nem családonként. Például amikor nagy ramos tokokat kerestem, a 16 bitesek között az 5V-osat én nem találtam meg. Ránéztem MC oldalon a család leírásra, és ott az volt, 3.3V-ig. Arról az egy példányról említést sem tettek, mint kivételről, hát nem is mentem tovább a szelektor menüre. Utólag már leesik, hogy valamikor már találkoztam ezzel a furcsasággal, és meg is akartam jegyezni magamnak, hogy majd jó lesz észben tartani, de természetesen idővel kiment a fejemből.

Ráhajtós microSD slot: Bővebben: Link Ő az.
Szerintem ez talán elég rugalmas, hogy bírja a rezgést is.
Ami ezekben az SD kártyákban belül van, azt azért nem találod meg sehol, mert olyan kivitelben léteznek csak, amit úgy sem tudnál házi/kisipari körülmények között felhasználni, emiatt a kutya nem veszi kiskerben, emiatt sehol nem tartják a disztribútorok, a nagy felhasználók pedig a gyárból szoktak rendelni közvetlenül.
Jobb esetben egy szem BGA chip, rosszabb esetben olyan, mint az LCD kijelző hátán a chip: tok nélkül rápakolva a panelra, és egy fekete szmötyivel lefedve. Ez pl. egy 512MB-os ilyen chip, természetesen BGA kivitelben. Ne hidd, hogy egy microSD-n több chip van...

Az igényedet kb. ezekkel lehet értelmesen kielégíteni:
- SD kártya
- NAND flash chip - ehhez viszont a PIC kevés lesz, beépített NAND vezérlős ARM esetén lehet értelme

SD kártya esetén a külön stabilizátort én nem használnám. Amit használnék, az vagy egy P MOSFET, vagy valami áramkorlátozós spéci load switch, pl. Bővebben: Link.

Ismerem a ráhajtós tokot (ott van a HEStore listájában is legelöl). De szerintem rideg. Lenne inkább műanyagból / gumiból fém helyett, sokkal inkább bíznék benne. Ha egy olyat használok végül (mert úgy tűnik, nem lesz más lehetőségem), valószínűleg kicsi nyákra fogom felrakni smd kivitelben, antisztati szivaccsal a nyákra ragacsolni két oldalán ragadó matricákkal egy smd panelen, és hozzákábelezni, vagy nem tudom.

Anno, ha jól emlékszem, pont ebben a topicban találtam egy olyan jelenséget, hogy pic-hez szalag kábellel hozzákötött SD kártya valamiért nem akart szuperálni. Milyen gondjaik lehetnek az SD-knek a kábelezéssel? Ilyen 20 mbps sebességig egy arasznyi szalagkábel még nem okozhatna gondot. Emlékszik még rá valaki? (Kerestem a felírást, de nem találtam meg.)

Az áram korlát ügyes dolog, de nekem olyan kell, hogy vezérlőjel hatására az össz áramfogyasztás max korlátja 100 mA-ről 2.5 mA-re zuhanjon. Nem pont olyasmi kell nekem. De tegyük fel, berakok egy olyat az SD elé. Akkor igazából mi is fog történni, amikor felveszi az égetési löketáramot? Megszűnik a tápfesz rajta? Éppen csak adatot felírni nem lehet majd? Mert az úgy nem segítség.

Ismeri valaki testközelből az MC demók MDD libjében az SD-SPI.c-t? Szenvedek egy project életre keltésével, és kutakodásaim szerint azzal akadok el, hogy már az sd alapinitje sincsen meg. "MEDIA_CANNOT_INITIALIZE" jön vissza. Látott már valaki azzal a libbel pic32-n sd-t életre kelni, vagy még azzal is számolnom kell, hogy broken az MC lib?

Kábelezés helyett lehet tüskesort használni, 20MHz-et valószínűleg elvisel.

Ott van a leírásában. Van, amelyik áramot korlátoz (megnöveli a FET ellenállását, és így lecsökken a kimenő feszültség), van, amelyik lekapcsol, és csak adminisztratíve lehet újból engedélyezni, olyan is van, ami lekapcsol, majd időnként visszakapcsol, hátha elmúlt már a túlterhelés/rövidzár.

Ha megszűnhet a tápfesz éppen írási műveletnél, resetbe dobhatja magát a kártya, és még alapinitelni is kell majd. Nem mintha lenne miért, ha egyszer írni áramkörileg úgysem lehet rá. Ha majd úgy alakul, hogy gyártanom kell egy nagyon gonosz misztikus hibát, ígérem, eszembe fog jutni, de jelenleg saját magamat szivatnám vele, az pedig nem áll szándékomban.

Nekem évek óta van a telefonomban egy mini (nem micro) sd kártya, köszöni szépen, jól elvan. A telefont rendesen használom, nem ütöm-vágom, de nem is az asztalon van egy helyben. Ez egy db-os adat, nem statisztika, de annyit talán mutat, hogy az sd foglalat azért nem olyan rettenetes dolog.
Stabilizátor miért kell? Nem elég egy p-fet? (ui.: most látom _vl_ kolléga is írta)

Én azt gondolom, hogy fejlesztésre egy jól méretezett P MOSFET pont megfelel. Az adatlapból kinézed a max. áramot, amit reálisan felvehet a kártya, ehhez kiszámolod, hogy mekkora lehet max. a FET ellenállása, hogy 0.2-0.3V legyen max. a feszültségesés, és ilyen FET-et választasz.
Éles készülékben viszont én nem kockáztatnám, hogy átmegy zárlatba a kártya, és lehidal a készülék betápja is. A "megszűnik a tápfesz írási műveletnél" problémakört nem tudom értelmezni. Ha a kártya az adatlapján megjelölt absolute maximumnál is több áramot vesz fel, akkor az már rég nem működik jól! Akkor értelmetlen azon meditálni, hogy mi van, ha elveszem a tápot tőle. Úgy kell méretezni az áramkorlátot, hogy normális működésnél még ne kapcsoljon be.
Egyébként diszkrét áramkörökből is összerakható (a MOSFET belső ellenállása, esetleg kiegészítve egy további ellenállással, és egy komparátor nézi, hogy mennyit esik ezen a feszültség, és ad interruptot a mikrokontrollernek, ha gáz van, az meg lekapcsolja az egészet).

Szia! Van más megoldás is az SD kártyára. Én is a HEstore-os foglalatot használom, de a mellékelt ábra szerint. Azaz fel vannak szépen pakolva mellé az spi-hez szükséges ellenállások és egy 10 pólusú csatlakozóra van kivezetve. Ez lehet tüskesor, szalagkábel csatlakozó stb. Ugyanezt használják a kínai (és nem kínai) fejlesztőkészleteknél is, azaz készen is kapsz 1-2 dollárért ilyen panelt. Nekem sokszor gyorsan kell, így cnc-vel nyomok egyet, ha elfogy, de a foglalat az említett HEStore-os. Így akár abszolút rezgésmentes elhelyezést is biztosíthatsz neki, maximum a szalagkábel fog rezegni, de erre is lehet jó megoldásokat találni. kínai nem kínai

Én is azon filoztam, hogy ha microsd akkor legalább egy külön modulba rakom tüskesorral. A nagyon nagy frekis környezeti rezonanciát máris kioltja, és az a leggonoszabb. Köszönöm a tippet.

SPI alapinit SD kártyákhoz. Az SPIxCON.SMP bitet (beérkező adat mintavételezési pillanata) érdemesebb átrakni bit idő végére, vagy maradhat bit idő középen? Ami SD specifikációt fel tudtam lelni a kérdésben, nem nyilatkozott róla. Ami libet fel tudtam lelni példa kódnak, mind tojik rá - hozzá se nyúlnak egyáltalán.

Nosza megpróbálom elhinni, hogy jó lesz az SD, de hobby építés előtt előbb egy már kész boardon keltenék életre egy példát. Az MC libekből amit találtam, továbbra sem akar életre kelni. A többi példa project sem volt hordozhatóbb állapotban, amiket fellelni tudtam. Már nekiestem lecserélgetni az MC libben lévő függvényeket, mert gyanúsan alapvető problémák mutatkoznak. Az alapinitre gyanakszom, mert még remélem, hogy nem maga a full lib a gagyi, ugyanis akkor sokkal többet kell majd s.k. megírnom.

Ha tud valaki segíteni, mi lehet a baja az alapinitemnek, és az író / olvasó függvényeimnek, igazán örömömre szolgálna. Pic32mx79, spi3-ra van kötve az MDD. A jellemző kód részletek:



Amennyire a lib környezetet megfigyelni tudtam, a put/get-ek mindenütt párjával vannak. Amikor vár valamit befele, minden alkalommal előtte 0xff-el írja a kimenetet, és ahol küld kifele bármit, mindig be is olvassa azt, ami azzal visszajött.

Amit eddig kihozni tudtam: timeoutig próbálkozással sem jön vissza semmi, és végül cannot_initialize hibaüzenettel kiszáll az MC initialize függvénye. Elakadni / lefagyni - ilyet legalább nem csinál.

Nem esett szó arról, hogy milyen kártyával használod. Lehet, hogy rosszul tudom, de az SDHC-t a MC nem támogatja. Én használtam az MDDFS API-t normál SD kártyával, nálam kínlódás nélkül elindult és működött is a FAT32 fájlrendszer SD SPI módban PIC24H-val.
Egyébként az, hogy 20 Mb/s és arasznyi kábel nem okozhat gondot az nem igaz. Nem az adatátviteli sebesség a lényeg, hanem az élváltások meredeksége. Én rámértem szkóppal az SD kártya által meghajtott vonalra 3-4 cm hosszú vezetősáv esetén is 1,5-2V túllövéseket tartalmazott (nem volt soros terminálás). Szóval a tanulság az, hogy mindenképpen érdemes a soros terminálás használata még rövid vezetékek esetén is.

Szereztem normál microSD kártyákat anno - nem keveset jártam érte, de végül sikerült. KingMax microSD 2GB. Teljes szektor kapacitas 3.840.000 szektor. Ezen kívül ami érdekes lehet, azt a laptop kártyaolvasójával meg tudom nézni róla. Nem SDHC.

De nem hinném, hogy azzal lenne gond. Néztem (természetesen lekerestem) a hiba helyét, és ami történik, hogy a kiküldött parancsra már nem érkezik meg a megfelelő válasz idő limiten belül. Ezután az MC lib még megpróbál kivárni, meg újra resetet küldeni rá, és ha akkor sincs elfogadható eredmény, akkor végül feladja, és azon a ponton lép ki az initialize függvény, ami ezen az ágon futott végig. Akár sd, akár sdhc de akár nem szabványos sdxc is lehetne, egy go_idle_state-et akkor is ismernie kellene, és ha végül le is fagy az alapinit, legalább nem azon okból, hogy a kártya egyáltalán nem válaszolt semmit sem.

Az áramkör maga nem halott, mert a boarddal együtt shippeltek egy bináris teszt alkalmazást is (csak egy .hex állomány van, forrást nem adtak ki), és azon meg tudtam vizsgálni, hogy hardveresen a board rendben van. Az sd kártya sem kampec, mert most is meg tudom nézni laptopban, hibátlan filerendszer is ott van rajta. Végig kotortam a libet, mi mindent küldözget ki és vár vissza:
-spi alap init, sebesség beállítás
-CS kapcsolgatás és pár 0xff kiküldés
-go_iddle_state parancs kiküldés
-status visszaolvasás (ami már nem jön vissza)
-mellék ágon kivárás, olvasás újra (status nem jön vissza)
-stop_transmission kiküldés - válasz nincs figyelve
-cannot initialize return
Ezen az ágon fut végig, és init failed. Az init későbbi lépéseire már rá sem tér.


Az áramköri tapasztalatokat köszönöm, pontosan olyasmik miatt aggódom én is. A viszonylagos problémám, hogy usb vonalon _összesen_ lehet 1 .. 10 µF kapacitás a tápvonalon (feszültség stabok alatt bárhol, pic-ek párhuzamos 100 nF kondijai, az rs-232 meghajtó táp szorzó kondijai), és erősebb szűrés abba nem fér bele. Amit neten találtam áramkört, az 220 µF + 22 uH + 4.7 µF tantál volt, amit én nem rakhatok majd oda. Ha csak 1µF tantálokat + 100uH tekercset használok, talán akkor is belül tudok maradni valamicske korláton, hogy legalább a pic tápját ne nyúzza le addig, hogy brown outra dob a lapka. Aztán ha mégsem működik, hát akkor hagyom az egészet a fenébe, és inkább csajozok a nyáron

De egyenlőre fényév távolságban toporgok még a végkifejlettől.

Üdv,
Szkópod nincs véletlenül? Nekem rengeteget segített abban, hogy kiderítsem, hogy hol hibázok, mondjuk nálam több volt a hibalehetőség mert 5v-os logikához kellett illesztenem a 3,3v-os kártyát és csak azt használhattam fel ami itthon volt. Neked a kártyafoglalat gyárilag vot ráforrasztva a panelre, vagy te magad kötötted be?

Szkópom nincs, csak házi "patikával" vagyok felszerelve. A boardot egészben vettem:

https://www.olimex.com/Products/PIC/Development/PIC32-MAXI-WEB/

Ha valaki éppen készül ilyet venni, előzetesben nem baj, ha tudja, hogy a szoftveres supportból nem kellene mindent elhinni. Az a freetos izé, amit adnak mellé, az egy mappába összemásolt mindenféle dolog, ami le sem fordul. A hardver normálisnak tűnik, de a szoftver fullra csináld magad akciós - a nulláról.