Kicsit talán pontosítsunk, miről is van szó igazából.

Írok egy példát. VS2005-ös project, kb 180k sor (egy ügyviteli alkalmazás, számos modulból), és a projectet már nem lehet átkonvertálni VS2010 alá. A 2010-es nem felülről kompatibilis a 2005-ös featurjeivel. Természetesen a cucc már elhagyta a fejlesztőit, a dokumentációit (pénz ki nem fizetéssel szakadtak meg egykori kapcsolatok), és nem is annyira normálisan lett megírva, hogy a szétszabdalása, és kiganéjzása egyszerű dolog lehetne. Számos modul jó néhány verziója, amik már időrendi sorrendbe se nagyon rakhatóak - a jelek szerint pár olyan modul lett később módosítva, amik mégsem kerültek felhasználásra. A kirakós találgatás nem hozott sikert. Páran ritka mód jót kuncognak a markukba, de bizony nem mindenki. Ha az a project szerkezetében nem egy olyan fejlesztői környezet sajátosságai szerint épült volna fel, amihez trehányságból megszüntetik a supportot, hanem forráskód szintjén állna egyetlen egységbe, amire tök ugyan úgy kell ráfuttatni egy compilert + linkert a régi környezetben is, mint az újban, akkor lefordulna az még mindig bármivel.

Persze annak helyt adok, hogy a fejlesztőknek nem igazán jön rosszul, ha időnként újra kell írni dolgokat. A munka az munka, és senki sem fogja elvégezni, ha nem fizetik ki. Épp csak arra kell vigyázni, hogy te azon az oldalon legyél, amelyik éppen jól jár a szituval. Teszem azt, ha neked kell fizetni, hogy egy alkalmazás minden fejlesztői környezet mérföldkőnél újra "modernizálva" legyen, mert két lépést egyben már nem biztos, hogy egyáltalán ki fog bírni, akkor szerintem át fogod gondolni ezt a dolgot, míg ha te vagy az a fejlesztő, aki a pénzt kapja érte, akkor a véleményed tekinthető jogos önérdek védelemnek, és abszolút elfogadható. Én mindössze arra gondoltam rávilágítani, hogy csak ne legyünk már elvakultak. A dolgok értelme vagy értelmetlensége nem egy globális igazság, csupán nézőpont kérdése.

Apropó kicsit gyakorlatiasabb téma. Leguccsó mplabx, mclib, kattintok .mcp file-on, mplabx elindul, és közli, hogy egyetlen file sem tartozik a project-be - pedig van benne vagy 10+. Abba a projectbe, ami demo gyanánt úgy érkezett egyben, ahogyan érkezett, és már megnyitni sem egyszerű - vagy csak én maradtam le valamiben, de nagyon. Szánom, bánom, szégyellem, de úgy mégis, hogyan szokás a mostani mplabx-el projectet megnyitni? Jelen esetben steps to reproduce: friss install uccsó mplabx, uccsó mc lib, dupla klikk usb device alatt az msd - sd card reader project mappában a pic32mx460-as .mcp-re, és látni fogod, mi is az, amit nem értek.

Valahogy konvertálni kell a projektet, nem csak simán megnyitni. Vagy pedig lehet, hogy van ott mplabx-es projekt fájl is.

Az MPLAB X-ben: File -> New Project -> Existing MPLAB IDE v8 project (jobb oldalt). A többi lépés értelem szerű. Remélem tudtam segíteni.

Köszönöm. Eredmény: 44 warning, 8 error. Vajon jól sejtem, hogy az egész mplabx az összes xc-vel együtt még inkább csak mutatóba van?

Jól elbeszélünk egymás mellett! Én a forráskód modulokba vagy fordítási egységekbe történő szervezéséről írtam, te pedig a fejlesztői környezetek faksznijairól keseregsz. A kettőnek semmi köze egymáshoz! Az általam említett koncepció egyszerűen, parancssori környezetben is megvalósítható. A te felvázolt problémádon viszont az sem segítene, ha egybe lenne ömlesztve a forráskód.

Én már kb .egy éve használom az MPLAB X-et és az XC fordítókat (8, 16 és 32 bites PIC-hez is), de eddig nem volt vele gondom, pedig minden projectnél bekapcsolom, hogy az összes warningot vegye figyelembe. El tudom képzelni, hogy az XC-s fordítók nem ugyan azokat veszik warningnak, mint a régi fordítók. Pl lehet az egyik szól, ha elfelejtesz return-t írni egy "non-void" függvény végére, a másik meg nem, vagy ha nem megfelelő típusú változókat adsz paraméterül egy függvénynek.
Olyan probléma viszont már volt, hogy egy programot XC16-tal fordítottam és működött is, majd ezek után elküldtem valakinek, aki C30-cal fordította. Neki is lefordult, viszont a program nem működött. Lehet csak a konfigurációs bitekben értelmezésében volt valami félre értés, de egyszerűbb volt letölteni ott is az X-es fordítót.

Az egész MPLAB X-szel nekem személy szerint 2 problémám van:
1. Mivel valós időben értelmezi a kódot, hogy van-e valami elírás, ezért mikor egy nagy kép bit mapját másoltam bele rendszerint lefagyott. Gondolom nem tudott megbírózni a sok adattal egyszerre.
2. Programozáskor minden egyes alkalommal újra csatlakozik a PICKit-hez és kiolvassa Device ID-t is. Ez nem sok idő, de ha ez az égetés és a fordítás is csak 10 sec, és az újracsatlakozás is ugyanennyi, akkor azért idegesítő.

Köszönöm a tippet, az mplab relatív problémámat inkább átraktam a kezdő topicba, mert nem ide való folytatnom.

Hmmm, a PICkit2, az MPLAB 8 és a C18 fordító "ejtésével" a Microchip mindent elkövet, hogy elüldözzön bennünket? Lehet, hogy sikerült...

Miért, az a "támogatás" amúgy olyan nagy szám?
Nehezen hiszem, hogy a hobbisták sűrűn igénybe vették volna a hivatalos supportot...
Amit most tud, azt meg 10 év múlva is tudni fogja, support nélkül is.

Már márcuis óta készülhetünk a váltásra.
Problémák:
- MpLab X -hez sok memóriával rendekező, új gépet nem lehet letölteni a Microchip oldaláról,
- A PICKit3 kezelő programja (más firmware letöltésével) gyakorlatilag PICKit2 -t csinál belőle.
- Az XC8 free módban igen gyatra, szinte az assembly szintre kell visszamenni (de van benne 16, 32 bites egész és lebegőpontos típus és műveletek)...

... csak holnapután nem lesz olyan gép, ami futtatná...

Na ne viccelődjünk már... Virtuális gép, bele egy XP, és kezitcsókolom.

Rám nem szólhatnak egy rossz szót se, minden egyes újabb MPLAB X verziót letöltöttem, feltelepítettem, kipróbáltam. Biztos bennem van a hiba, közel 40 év programozási gyakorlat alatt kialakulhatott némi beidegződés, azt elismerem, hiszen ezt az új programnyelvet ( a C-ről beszélek ) sem tudtam igazán megszokni, pedig annak is nekifutottam évente, de az MPLAB X láttán biztosan már irányba indultam volna el ...
Amikor pár éve választhattam, hogy milyen irányba induljak el mikrokontrollerek terén, az MPLAB8.x és a PICKIT2 átlátható egysége volt a fő érv a Microchip PIC mellett. Kezdőként is átláttam, és hatékonyan tudtam használni. Már a PICkit3 is olyan béka volt, amit nagyon nehezen nyeltem le. Most pár évig még elleszek, de egyértelmű a váltás, marad a Raspberry. Ha egy cég tönkre akarja tenni magát, akkor tegye.

[off]Megmondom őszintén, nekem semmi bajom nincs az MPLAB X-szel. Sőt én személy szerint nem is értem, hogy hogyan tudtam eddig meglenni azok a dolgok nélkül, amit az MPLAB X tud. Real-time értelmezés, Ctrl + klikk-re a deklarációra ugrik, kitudja egészíteni az include-ban az fájlnevet, elérési útvonalat és struktúrákat is. Szerintem manapság ez a minimum egy fejlesztő környezettel szemben. Ha még a sima változó és függvény neveket is ki tudná egészíteni az már teljes mámor lenne számomra . Persze ezeknek a dolgoknak inkább nagy projekteknél van jelentősége, hiszen nem sok értelme van, hogy az ember tud ugrálni a 3 darab c fájla között, de mikor mondjuk 50 c és 50 header fájl egy program én nagyon örömmel vettem, hogy nem kell minden függvényt kikeresgélni, hanem csak klikk a függvény nevére és más ott is van az implementáción. Utána pedig Alt + balra nyíl és vissza lép az előző szerkesztés helyére.
Az való igaz, hogy kell neki RAM és komolyabb gép úgy általában. De szerintem 2013-ra jogosan indulnak ki fejlesztő abból, hogy az emberek gépében nem 512MB RAM van.
Egy másik fontos dolog szerintem, hogy platform független.
No, ennyit szerettem volna elmondani az MPLAB X védelmében. Meg lehet kövezni érte, de nekem nincs vele semmi bajom, sőt éppen ellenkezőleg. Ha nem próbálnának mindig kitalálni valami újat még mindig a PIC16F628 lenne a csoda, mert hát eddig is jó volt az.

Én is kipróbáltam, 4magos erőművem van, de lassú volt és lefagyott rendszeresen, volt vele más bajom is a java alap miatt. Szerintem visszalépés. Talán ha nem fagy le rendszeresen és koforrja magát...

Mire idáig eljutnánk, addigra már rég át kell térni az MPLAB Y, vagy MPLAB Z-re. Pont ez a bajom, hogy mindig misszionáriust játszanak (térj át erre, meg amarra...), ahelyett, hogy a régit raknák rendbe.

Én továbbra is kitartok amellett, hogy itt volt az ideje a váltásnak, de hát nem kell mindenben egyet érteni.
Viszont érdemes belegondolni abba, hogy a régi MPLAB verziószáma 8.x. Gondolom azt is 1.0-val kezdték sok sok évvel ezelőtt. Tehát rengeteg idő volt míg kiforrta magát. Ezzel szemben az MPLAB X szerény véleményem szerint max. 2 éves történet és jelenleg az 1.80-nál jár. Azért ez lényegi különbség. Persze azt maximálisan megértem, hogy akinek nincs semmi baja a bejáratott régi IDE-val, azt most átkényszerítik az ahhoz képest kiforratlan csillivilli új változatra. A választás lehetőségét valóban meghagyhatták volna legalább addig, amíg az MPLAB X is el nem jut stabilabb szintre.

Nem kötekedésképpen írom, de azok a pozitívumok, amiket emlegetsz az editort jellemzik. Ugyanezeket egy néhányszor 10 MB méretű CodeBlocks is tudja.

Egyetértek Egyébként Te próbáltad már a CodoBlocks-ot PIC-hez? (mert én még nem)

Az Em::Blocks nevű változatát próbáltam 1-2 éve. A magam részéről nem láttam értelmét a használatának az MPLAB-hoz képest (főleg hogy eleve az MPLAB fordítóit használja). Másnak más szempontok alapján hasznos lehet.

Konkrétan, ha PIC-re fejlesztek (mostanában nem nagyon), akkor a CodeBlocks-ot használom editornak, a debug-t meg a fordítást az MPLAB 8.x alatt végzem. Régebben kipróbáltam az MPLAB X-t is, de attól függetlenül, hogy modern a felület, számomra nem volt használható. Sokat kellett vele nyüglődni. Ez persze régebben volt, mostanra már lehet, hogy sokat javult a helyzet, ezt nem tudom.

A rasp realtime gépként már majdnem olyan gyors, mint az mplabx

Az MPLAB 8.x editora gáz. Szerintem ez nem képezheti vita tárgyát. Viszont megtámogatva egy jó editorral, már egész jól használható a rendszer. Nem feltétlenül kell a CodeBlocks-t használni fordításra, meg debugra.

Lehet tényleg az lett volna megoldás, hogy a meglévő maghoz csinálni egy új editort vagy csak pár extra feature-t. Viszont akkor még mindig nem lenne megoldva a platform függetlenség kérdése, ami nem elhanyagolható manapság, hiszen már közel sem mondható el, hogy a Windows egyeduralkodó.
Először én MPLAB X-ből az 1.10-et próbáltam. Az tényleg katasztrófa volt. De most jött ki az 1.80! Lehet direkt az én gépemre fejlesztik, de nekem megy, nem fagyogat le, nem lassú

Ezért írtam, hogy nem feltétlenül az a mérvadó amit mondok, régebbivel próbáltam csak, de az elvette tőle a kedvem. És mivel jól elvagyok a régi MPLAB-bal is, egyelőre nem váltok. Mondjuk nem tudom a többieknél a legújabb van-e telepítve, vagy a régebbivel való rossz tapasztalat mondatja velük a negatív véleményt.

Én használtam a Netbeanst évekkel ezelőtt Java-ra, és nem voltak gondjaim vele (ill. de, egy: az alap billentyű-kombinációkból pár irritált). Na ebbe tákolta bele a Microchip a saját dolgait, azaz lényegében egy már szinte teljesen kész, évek óta kiforrott IDE-hez rakott hozzá pár kiterjesztést, sémát (pl. a debug rész, az ugye teljesen Microchip-specifikus), a nagy részét tehát meg sem kellett írniuk az egésznek. És ennyi is elég volt nekik ahhoz, hogy a felhasználók egy nehézkesen, rosszul használható valaminek lássák a végeredményt - na én ezt tartom szomorúnak.
Egyébként pedig ha az összes szoftverük fejlesztését kiraknák open-source, közösségi projektekbe, meg merem kockáztatni, hogy több tehetséges embert találnának rájuk, mint amennyit alkalmazottként össze tudtak gyűjteni. Legalábbis a végeredmény tuti jobb lenne ennél...

Nem próbáltam, de gondolom MPLAB X alatt lehet használni C18 fordítót, illetve nem kötelező az XC n? Lehet, hogy tényleg jobb lett az 1.80, talán megér egy próbát a szerkesztője, mert az tényleg tetszett volna, ha...

Természetesen lehet használni C18-at is.

Hát szomorú, ha tényleg "csak" átalakítás volt. Ami még szomorúbb, hogy nagy projekteknél pont a debug rész nem ment rendesen....

Pic10F-ekkel játszadozott már valaki? Elvileg azokon is van egy oszci be és kimenet, igaz, nem pont olyan, mint a többi picen. Van arra kitalálva valami, hogy azt meg lehessen hajtani sima kvarccal / rezonátorral, vagy mindenképpen külső kvarcoszcillátor kell hozzá?