Még amikor 100kHz volt akkor néztem és stimmel. Most nem vagyok gép előtt, nem jut eszembe a neve, az Elm Chan féle.

Ez a fat16/32 dolog nincsen jó helyen a tesztben, nagyon sok mindentől függeni tud. Ha tesztelsz, és a szűk keresztmetszetet keresed, akkor lépésenként kellene haladni.

Első körben hagyd a fat cuccokat, és csak nyers szektor írás / olvasást tesztelj. Szerintem van rá lib, hogy közvetlenül az sd kártyát parancskódokkat és adatcsomagokkal bombázd. Kotord fel a multiszektor módot is, és teszteld azzal is a random 512 byte olvasás (1 lba szektor) után a random pozíciós 2,4,8,16,32,64,128,256,512,1024 szektor olvasásokat (ez a leguccsó már fél megabyte). Az órajelet kezdésnek vedd fel 25 mhz-re, ha azzal is stabilan működik. Mindegyik mérést ismételtesd meg vele legalább 100x, és a mérésekből jegyezd fel a legkisebb, legnagyobb, átlagos időket. Lehet ez így sok macerának hangzik, de valójában csak halom sok ciklusról van szó, amik 1-1 számban különböznek egymástól, forráskód szintjén ennek a nagyja halom sok copy/paste és semmi több, a végén pedig kihajítja neked a halom sok adatot.

Csak azt az egy kártyát teszteld kezdetben, amiben a leginkább bízol, mert mindegyit tesztelni sokáig fog tartani a nyomozósdi.

Ha megvannak a nyers sebességek, utána lehet olyasmit is megpróbálni, mint beolvastatni fat driverrel teljes fat táblát, ha olyat is tud, utána generálni ismert szerkezetű kicsi filesystemet, valahogyan logolni, hogy összesen milyen olvasási kéréseket dobál ki, és legfelső szinten mérni a sebességet. Ha azt összehasonlítod a nyers olvasási sebesség adatokkal, akkor lehet majd kideríteni, hogy maga a filesystem kód ami cpu-t elvisz, hány %-al lassít a nyers sebességhez képest. Ha túl sokat, majd akkor lehet azzal is játszadozni, hogy azt a kódot nem flash-ből, hanem ram-ból hajtani végre, és megnézni úgy is. De nem kell annyira előrerohanni. Kezdésnek küld csak neki a hardvert a szektorolvasásnak.

A sebességről egy tipp: mindig írd ki, hogy kilobit vagy kilobyte, mert bár általánosságban a "b" bit-et, a "B" byte-ot jelent, mindig mindenki el szokta figyelmetlenkedni. Kiírva a jobb.

Más téma, egy jellemző szavazatot kérnék tőletek, amolyan első dolog, ami eszetekbe jut, még a két választási lehetőséget is megadom

Ahogy növekednek a cpu teljesítmények, egyre inkább neki fog szaladni a pic világ a multimédiás cuccoknak. Például ez a flash kártyás játszadozás is olvasásra még okés, de az írás szét koptatja write back cache-elés nélkül a flash-t wear leveling ide vagy oda. És akkor még nem is mini adatbázisokkal játszadozik a pic világ, mert odáig még el sem jutott.

Részemről másfél éve dobozban tartom az ötletet, hogy nagyobb méretű blokkos ram perifériát fejleszteni pic / avr / cortex-m/r kategóriás cpukhoz. Egy gyors véleményt kérnék róla, hogy szerintetek az ötlet szuper vagy suxx?

Mit takar ez a nagyobb meretu blokkos ram periferia?

Ha a piacon keresgélek, nem nagyon van nagy méretű SRAM, amit könnyen lehetne illeszteni PIC-hez. DRAM-ot nemigen lehet illeszteni, legalább is nem könnyen(ezzel még foglalkozni akarok, de most nincs időm egyelőre). Most ez az EBI port az MZ-ken jó irány, talán lehetne rá találni RAM megoldást, de pl. chipcad-nél nem nagyon vannak nagy méretű(>16MByte) RAM-ok. Lényeg, hogy jól jönne ilyen. Jelenleg milyen kényelmes lenne a hátteret RAM-ban tárolni és onnan kitolni TFT-re. Rögtön lehetne dinamikusan kezelni a képernyőt. Így csak újrarajzolgatás és statikus dolgok jöhetnek szóba.

Még esetleg annyit ehhez, hogy egy 32Mbites SRAM 26ezerFt+Fa, egy 32Mx16bit SDRAM 3200Ft+Fa. (igaz az EBI csak 16MBytig tud címezni, de bontani is lehet lapokra...)

F-RAM

Szia! Tetszik (új technológia), de SPI, max 40MHz és kicsi (512KByte).
Ellenben az ATMEL EBI-je kezeli az SDRAM-ot... (Mekkora gáz és talán butaság lenne egy atmelt SDRAM interfésznek használni PIC mellé. )

Miért? Mind a kettő Microchip termék lesz nemsokára....
Egy másik 32 bites (ARM, stb) kontroller nem lenne jobb a feladathoz?
A DRMA frissítéstől tartasz? Vedd át a PC -k módszerét. Egy DMA csatorna, amit egy timer indít, minden sor (raw) címről olvas egy adatot. Ezzel meg is van a frissítés...

Ilyen tekintetben nem gáz.
(ARM?) Igen, erre akartam utalni, hogy egy ARM mennyivel...
(DRMA) Igen, talán nem venne el sok időt, de elvenne. Jobb lenne, ha harver támogatná.

Hát! Nézegettem a kínálatot (kaphatót). Azonos árfekvésben a PIC32MZ magasan viszi a pálmát. Csak az EBI ami "butább". Jelentősen gyorsabb (3x), nagyobb Flash (4x), RAM(16x), SQI, Ethernet és még pár dolog. Az MZ EF sorozat erratája jelentősen lerövidült, lényeges dolgok nincsenek benne (persze lehet, hogy még nem érkezett annyi visszajelzés, de egy év alatt talán már igen...) Ha most választanom kéne, csak az SDRAM támogatása miatt nem ARM-et választanék...

Egyébként az SDRAM sebessége csalós. Igaz 100MHz feletti órajalet fogad, de az MZ EBI csak 50MH-z-es. Egy adat kiolvasásához elég sok beállítás szükséges, igaz, amikor burts-ben olvasunk gyors, de a DRMA-ról akkor nem szóltunk. Az EBI 50MHz-e és a 16bites szélesség azért hoz vissza a hátrányból, MZ szinten talán nem nevezhető lassúnak összességében. Van itthon pár régi SDRAM-om, egyet ki fogok próbálni, ha odaérek!

Ellenben egy ATSAME70Q21 megér majd 10ezret. 300MHz, 2Msps 12bit ADC, EBI SDRAM támogatással(is), MMC/SD port, és minden ami szem szájnak... Ezzel lezárnám az offot...

Nem állítom,hogy a Mirochip-nél is ez lesz,de például az Atmel is időben (vagy inkább későn) rájött,hogy a saját 32-bites zsákutca,és már futtatja is ki .Elég csak ránézni a Cortex-M licenszelők listájára.

Nocsak, én azt hittem teljes érdektelenség fogadja majd a kérdést

Másfél éve forgatom a fejemben, hogy fogni egy lpddr-t (van 32 megabyte-tól 1 gigabyte-ig akármekkora pld a micron-nál), odarakni egy fpga mellé. Csinálni mondjuk egy 256 megabyte-os soros ram breakout modult.

A mezei dram tokok pakolásán anno én is elfiloztam, de azok a tokok, amiket még klasszikusan frissíteni kellett, olyan sebességgel, amivel egy pic is el tudhat boldogulni, azok az 1 megabites tokok környékén véget érnek, és akkor már ott az mc soros ram. Apropó részemről sosem értettem, mire jók azok a soros ramok. Nem multimédiás kihívásokhoz termett a kapacitásuk, másra meg mire kellhet? Egyáltalán veszi azokat bárki is? A chipcadnél azt látom, kajak leáraztak egy egész pakkot belőle, ami nem arra utal, hogy állandó lenne rájuk a kereslet.

Az f-ramok is kb az a kapacitás, hogy a semmihez sok, a valamihez kevés. Azóta már vagy 3-4 cég megvette / viszont eladta az ötletet. Kapacitásban továbbra sem sikerült áttörést elérni. Szerintem nem igazán találnak neki piacot. Valamikor bíztam benne, de csak nem akar fejlődni.

Speciel en FRAM-ot FLASH journal-hoz hasznalok. A Ramtron kitalalta, a Cypress megvette. Nem volt ott olyan sok adas-vetel, ha jol tudom.

Tudom, hogy nem ezt mondtad, de a mikrocsipnek nem is volt soha sajat 32 bitese, mert a pic32-ben egy kb. 20 eves MIPS (m4k) core van.

Úgy tudom hogy a Microchip megvette az Atmel-t.
Mi lesz most?

Az AVR is bugos lesz.

Ettől félek én is, bár a 8 bitesek mind a két gyártónál jók.

PIC18F25K20 errata csak 41 tétel.

Ahhoz túl magas volt az összeg(vételár),hogy csak úgy bedarálja.Felérne egy lábon lövéssel. Azóta is jöttek ki új avr-ek,még Xmega is,pedig ez lett volna az első tippem, mint áldozat.

Omg, nem lesz többé sem avr sem atmega?

Amennyire a híreket olvastam, egy részt pénzben fizettek ki, egy másik részt részvényekben, de azokat szándékoznak visszavásárolni. Egyenlőre azok a billió dolláros tranzakciók egészen nyárig fognak eltartani, gondolom, az erőteljesebb változások utána következnek.

Az XMEGA jó csak még nem tudtam megérteni a működését, teljesen más mint az ATMEGA vagy a 16 bites PIC család.

Nem eszik olyan forrón! Igaz, idő kellett, de az MZ EC is kikupálódott EF formájában. A két PIC gyakorlatilag egyforma, (CAN és lebegőpontos aritmetikai egység csak bónusz). Ez bíztató, foglalkoznak vele, stb.

Szerintem nem változik semmi, legfeljebb jó irányba. Ami az AVR-ekben jó az átköszön és viszont. Lesz továbbra is minden típus, ami eladható, legfeljebb az ATMEL helyett a Microchip logo lesz ott...

Meg az arduinot átnevezik picudinóra (atmegák vannak mindegyikben)

Nem igaz mert már van PIC32 -vel arduino is az MPIDE, nem rossz csak bugos kissé.

Vagy PINGUINO

A hardver oldalától annyira nem félek, de az example oldaláról igen. Az AVR-ekhez szép világos példákat láttam, sokszor azokból merítettem PIC-re is. A harmony egy nagy kalap csoki. Arra jó, hogy valaki bután elindítson egy alkalmazást, de példának nulla. Százszor egymásba ágyadott definiálások, aminek a vége egy utasítás, vagy egy holt egyszerű függvény, de az is semmitmondó, mert nem látod rendszerben, csak szanaszét a dolgokat. Ha látni szeretnéd a lényegét, mondjuk egy beállításnak, akkor egy katyvaszt látsz. Ez minden, csak nem példa. Ha ezt a szemléletet átültetik AVR, ARM-re is, akkor véleményem szerint sokat veszíthet az, aki eddig azon a vonalod dolgozott. Arra nagyon kevés esélyt látok, hogy fordítva történjenek a dolgok (mert egy igazi jó példa programhoz, sokkal több munka kell és okosabb, ügyesebb programozók). Remélem sok negatív visszajelzést kap a Microchip és észhez térnek!