Nem erre a következtetésre kellene jutni....
Az EDS területen definiálható tömb maximális hossza 32768 byte. Azonban - ha van a kontrolleren elég memória - több ilyen tömb is létrehozható. A kezelésük egy 32 bites mutatón keresztül történik. Az igényelt és a létrehozható struktúrák címzése közötti leképezés eljárásokkal megoldható.
A régi szép idők jutnak eszembe, amikor a Midrange 16F -eken kellett 80 bíte -nél nagyobb "struktúrát" kezelni.

Ott van memória is bőven. Valamint van c++ is.

Ideje volt végre megérteni a burkolt célzást

De ha még mindig lennének kétségeid, természetesen szétszabdalt memóriát is lehet használni, viszont a wrappert neked kell megírnod hozzá. Nem olyan egyszerű a dolgod, hogy csak definiálod a logikailag egy darab jó nagy változót. Helyette, definiálsz egy függvényt / makrót, ami adatot mozgat külső változók és az adattár között. Abban implementálhatod a különféle területek elérését külön-külön. Az egyes területek elérését optimalizálnod kell az adott mikrovezérlő tulajdonságaihoz. Tudod, olyasmik, mint azzal kezdeni, hogy előbb elolvasod a mikrovezérlő adatlapját a legelejétől a legvégéig. És azt mindig megteszed majd, ahányszor egy új pic családdal akadsz össze, mert a régit kinőtted. A lényeg, hogy sohase térj át egy akkora erőforrásokat kínáló pic-re, amivel kevesebbszer fordul majd elő, hogy minden héten újabb ezer oldalnyi adatlapot kelljen elolvasnod. Attól kell megrémülni, hogy adatlap mennyisége a pic32-nek is van, és hogy az milyen sok. Ha sikerül rendesen megrémülni tőle, akkor lehet majd úgy végezni, hogy végül 20x annyi adatlapot magolhatsz. Mert hát egy logikus világban élünk, és a logika gyönyörködtet

A microchip most dobta ki hivatalos formában a dupla magos 16 bites pic beszámolóját ( Bővebben: Link ).

Egy hete már készül valami...

Nem akarok extrém vészmadár lenni, de ugye nem teljesen feleslegesen készül? Az a 16 bites pic 2 maggal sem biztos, hogy érni fog annyit, mint egy őskövület pic32-es. Rövidebbek a HW bufferek, kommunikációt kell szervezni a magok között, energiafelhasználásban sem hatékonyabb, szóval szép-szép, csak mondjuk elkésett vagy 15 évet.

Másfelől nézve ezekkel megoldható, hogy a frissítés letöltése, ellenőrzése alatt is zavartalanul menjen az (időkritikus) folyamat (a slave magon).

Mi az aminek futni kell frissítés közben?
Szinte minden eszköz használhatatlan frissítés alatt. Sőt, kritérium, hogy ne nyomkodd és hasonlók. Nem hiszem, hogy ez olyan nagy probléma.

Visszakérdezek, milyen alkalmazásokhoz kell a dsPIC (digital signal processor)?
Példaként egy napelem invertert vennék, amiben frissíteni kell (mert manapság még a sétabotban is mindig frissíteni kell) a programot. A slave mag viszi a hálózattal való szinkronizálást, a terhelés figyelését, a feszültség és a frekvencia szabályozását. Milyen következménnyel járna, ha ezek a funkciók sok-sok másodpercre nem tudnának futni?
A firmware letöltése, verifikálása a master magon történhet, csak neki van program flash memóriája, az ő idejét viszi el az adminisztráció. Ha jól van megírva a slave program, szépen lassan átveszi az új verziót a program RAM egy területére miközben egy másikról fut. Ha végzett az átvétellel, egyszerűen áttér az új területre - minimális idő alatt.

Mindenesetre a kipróbáláshoz még jól jöhet...

Igen, lassan a WC-t sem lehet lehúzni frissítés nélkül.Addig nyilván le kell kapcsolni a hálózatról. Nem tudom, még nem frissítettem napelem invertert. Eddig is megoldották valahogy. Egyébként biztosan igazad van meg értem én, hogy haladni kell a korral, de akkor miért nem a 32 bites struktúra?

Az Atmel -től 8 illetve 32 bites kontrollereket vettek át. Szerintem azon gondolkodnak, hogy melyik család marad életben egyáltalán.

Pic32-ből még az mx-ben is ott van 128k ram. Ha nem terhelik túl a pic-et, simán ram-ban elfér a teljes program a munkaváltozókkal együtt, és mellette azt ír bele a flash-be, amit csak akar. Ketté is lehet szedni a flash-t és a boot-ról ellenőrizni a feltöltésüket arra az esetre, ha frissítés közben szakadna meg a folyamat, és a hibamentes verzióhoz kell visszatérni. Igazán sajnálatos, hogy olyan szoftver koncepciót nem dolgoztak ki pic32-re rendesen. Viszont 16-osra sem. Már amennyire én figyeltem az eseményeket. Mindenképpen meg kell írni. Szóval végső soron csak a hardver van adva. És akkor a kérdés ugyan az a végén is, mint az elején volt: ha eddig nem csinálták meg, most minek erőlködnek vele?

Nem is tudom, minek strapálja magát a MC, hiszen a legegyszerűbb feladatokra is mindenki az XCORE chipek legnagyobbikát használja fel: Adatlap 16 mag mindenre elég lesz. Be is lehetne zárni a céget...

Ha lenne olyan magból tényleg normális, bizony rendes érvágás lenne rajtuk.

Kicsit kisarkítod, mert egy 16bites és egy kistokú 32 bites között nem nagy árkülönbség van és akkor inkább MX, vagy MZ. Megaztán könnyű megszokni a jót, mert 32bit után 8bit 16F-re visszatérni, csak egy módosítás erejéig is olyan érzés, mint ha egy fullos luxus autóból át kéne ülni gyerekkorom lábbaltekerősébe! De értem, hogy mindenre a megfelelő eszközt kell használni, ezért vannak skálázva és nagy darabszámok esetén minden fillér fontos, ellenben amatőr szinten egyszer ezer Ft nem oszt-nem szoroz és tényleg kényelmesebb és talán megfelelőbb is sokszor. Majdnem olyan, mint ha PC-t programoznék, ami számomra megfelelő ellenértéknek tűnik. A fejlesztés sebességéről nem is beszélve. De ettől még ezt a helyén kell kezelni...

Ha már a PC is szóba jött MZ-re C++-ban összeraktam C#-os IObject base class-t ami egyenlőre csak ToString-et tud és szépen a CLR-ből szedtem hogy formáz a C# (meg írtam String class-t) + Intx+UIntx+Float osztályok operator overloading és most a 3 soros sprintf-ek helyett 1 sor-os ToString.
Nem hangzik nagy előnynek, de mivel nem időkritikus az alkalmazás rohadt kényelmes, hogy sok mindent csinál helyettem a software.
"Mindennek meg van a maga böjtje..."

Mottó:
"Ha üzletet szeretnél csinálni, keress egy hézagot (amiben nincs termék), gerjessz rá keresletet, majd elégítsd ki azt..."
dsPIC33CK256 ~ 4$, dsPIC33CH256 ~ 4$, PIC32MZ0512EFF ~ 7..8 $ (Microchip Direct mai, 1..25 darabos árai alapján) Jelentős árkülönbségnek mondanám.

Váram a JAVA alapú PIC32 -re épülő megoldásokat.

A java még csak ezután jön!! Bocs...

Egy dsPIC33FJ256 azonos lábszámú kivitel esetén drágább, mint egy 32MX360.
Ennek ellenére mindent értek, amit képviselsz, de engem nem győztél meg, akkor sem, ha kétszer annyiba kerülne minden esetben a választás, ami nem igaz, mint láthatod.

Magad világítottál rá az új típus kifejlesztésének egyik fontos jellemzőjére: A "kétmagos" dsPIC33CK/dsPIC33CH (100Mips) fele annyiba kerül mint az "egymagos" dsPIC33FJ256 (40Mips).
Van remény akár a "kétmagos" PIC32-kre is: Vékonyabb csíkszélességű technológiára tett szert a Microchip a felvásárlásokkal.

Ez jól hangzik. Remélem az erraták is csökkennek a csíkkal együtt.
Nézegettem 32MX-eket, az MX210F016B SOIC 28 és 580+Fa (kapható). Kicsi a bors de olcsó. Vannak lehetőségek kicsire is és nagyra is 32bitben is, ez biztosan nekünk, műkedvelőknek a legjobb!

Sajnos nem ez a tapasztalat. Amin épp fejlesztek 32MX annak is 50 pontos erratája van és nem adtak ki új revíziót. Ha a régit sem tudják kijavítani a még komplexebb architektúrától se várj jobb erratát.
Nem beszélve, hogy egy egyszerű 8 bitesben is alapvető problémák vannak néha.

Neked volt már olyan, hogy nem tudtad megoldani a hiba miatt a feladatot? Velem egyszer fordult elő, hogy egy(3db-ot) 32MZ-t gyakorlatilag kidobtam a kukába, mert oda való volt (ECH), de a több másik "száz" esetben azért mindig sikerült megoldani valahogy. Nem vészes. Csak abban lehet reménykedni, hogy tanulnak a korábbi hibáikból, esetleg ellesnek megoldásokat az AVR-ek megoldásaiból.

Új Microchip programozó! Ugyan az a 300MIPS-es 32 bites mikrokontroller van benne mint a PICkit4-ben és az ICD4-ben, de csak 5300Ft:
Bővebben: MPLAB Snap

Kimondottan tetszik.

Igen, már volt róla szó a másik témában. Én megvárok 1-2 véleményt.

Még nem kellett kukáznom errata miatt semmit, mert igyekszem átnázni előtte, viszont változhat fejlesztés miatt valami ami miatt olyan részre tévedhet az ember ahol hiba van, meg találtam már többször is errata nem említette hibát és nem kimondottan tetszik, ha emiatt át kell drótozgatnom a panelt meg programot javítgatni, na meg órákig, napokig keresni, hogy akor most hol is a hiba. De azért általában nekem is sikerül valahogy kikerülni ezeket, hogy ne kelljen kukázni az egészet.

Azért egy üzleti alkalmazásban elég ritkán fordul elő, hogy kiveszel a gyártásból 10 darabot, hogy na ezeket most megdrótozva akarod eladni az ügyfélnek

Amúgy igen, errata létezik, de nem csak 32 biten, hanem 16 meg 8 biten is. Kicsit fáj a hócipő miatta munkafolyamat, de áramkört nem vakon tervezünk, hanem előbb megnézzük a szükséges erőforrásokhoz tartozó errata pontokat, és utána gyártunk kapcsolást, amit szintén külön csekkolunk egy deszka modellen.

Ami fejlesztés közben változik, leginkább pár szoftveres igény, amihez nem kell másik kapcsolás. Egyszer megírtad a hardverhez tartozó alapokat, fogalmam sincs, utána még mibe tudsz beleakadni.

Ha akarsz olyan szöcskéket, amiknek rövidebb az erratája, ott vannak az LPC-k az NXP-től. Ha akarsz egy tippet, azokkal meg olyan baj van, hogy az opensource supportjuk nem éppen a legjobb (mondjuk az MZ-nek se, de az MX-ek kicsit sem panaszkodhatnak azon a téren). Még a problémáival együtt is a pic-re fogsz visszatérni később ha csak nem valami repülőgép elektronika vagy olyasmi a cél, ahol szakmai audit elejétől a végéig mindent átnyálaz, és ha pic-et talál, kukába dobatja a fejlesztést.

Van néhány pont, amiben eltér a PICkit4 -től, főleg az ár leszorítása miatt:

A csak High Voltage Programming módon programozható típusokat nem kezeli !

Ezt hol találtad?