Forum micro-chip - mplab ide x

Pentru regret, am întâlnit faptul că stocarea setărilor proiectului în MPLABX este organizată analfabeți.

Există un proiect pe care lucrează 2 persoane, de la distanță. Unul utilizează ICD3, altul utilizează PICKit3. Pentru organizarea codului sursă se utilizează VCS (în acest caz este Mercurial, dar nu contează)

În 8-ke, debuggerul folosit (adică, ICD3 sau PICKit3 sau altceva) este stocat într-un fișier .mcw, adică în setările spațiului de lucru. Acest fișier mcw nu este adăugat la depozit deloc, doar mcp este în grapă. Astfel, fiecare dezvoltator utilizează un "mcp" generic și propriul mcw personal. Acest lucru funcționează excelent, fără probleme: oricine poate folosi orice instrument pentru depanare.

Dar în MPLABX organizat mult mai rău: depanatorul selectat este stocat în fișierul principal al proiectului, adică în
.X / nbproject / configurations.xml. împreună cu toate fișierele primite în proiect, cu toate include traseu etc. Desigur, nu putem include acest fișier în proiect și avem constant o schimbare parazită în acest fișier, tot timpul există conflicte.

Este o soluție mega-stupidă. I-am prăjit câteva zile în urmă pe forum. dar până acum nici un răspuns.

Mai mult decât atât, există un fișier în proiect .X / nbproject / private / configurations.xml. stochează setările unei anumite stații de lucru - de exemplu, calea spre compilator. Desigur, acest fișier nu este conectat la proiect și este evident că debuggerul selectat trebuie, de asemenea, să fie stocat în acest fișier.

Foarte mult mă îndoiesc că există o metodă de tratament, dar doar pentru că voi întreba: cineva știe, cum să se vindece?

Chiar dacă lucrez singur pe un proiect, încă lucrez nu numai la birou: uneori, laptopul meu este acasă, iar instrumentul este diferit. Din nou, o schimbare parazitară de fiecare dată când vă schimbați locul de muncă. Deoarece este insultă, restul în MPLABX se potrivește destul.

Inițial Adăugată pe site de dimonomid (Сообщение 167598)

Foarte mult mă îndoiesc că există o metodă de tratament, dar doar pentru că voi întreba: cineva știe, cum să se vindece?
.

Aici, mediul în sine trebuie să fie refăcut. Nu-mi amintesc ce am avut de spus - a fost ceva atât de global. În general, sunt întrebat ce instrument doriți să utilizați (Pickit3, ICD3, etc.). Cu doi debugeri conectați simultan, există un bug - totul funcționează, dar cuvântul de configurare nu este scris astfel. Ie nu funcționează deloc.

Dacă cineva utilizează PIC32, MPLAB X și programatorul (ISD3 de la mine), atunci fiți atenți la descărcarea a două proiecte miercuri. Încă nu mi-am dat seama ce și cum, dar apoi se schimbă sectorul de boot al operatorului. La mine acum doar la lucrările de depanare, și într-un mod normal nu vrea să fie lansat.

Inițial Adăugată pe site de Romantic (Сообщение 167769)

La mine, la citirea subiectului dat, a existat o întrebare: este întotdeauna așa - produs brut în care câțiva ani la coderi obișnuiți (nu la testeri pe salariu!) Este necesar să prindă bug-uri infinite? Sau este Melchochep atât de distins? M-am hotărât că atâta timp cât acest subiect nu se oprește de o jumătate de an, nu voi merge la X. Din nou, și cu resursele pe computerul de lucru nu este grasă, poate că pur și simplu nu trageți astfel de mastodon. Sincer, nu știu de ce să fac o astfel de resursă exigentă. Este ca și cum ați scrie un mediu de dezvoltare pentru Macromedia Flash: p

MPLAB X a fost realizat pe baza NetBeans, care a adăugat subtilitățile programării pentru controlori. Există o mulțime de gusturi, începând cu înlocuirea automată a unor nume care se termină cu lucrul cu depozitele. Uneori, de asemenea, observ că programul se blochează pe interfață timp de 20 de secunde într-un loc complet inofensiv. Luați, de exemplu, Eclipse, este, de asemenea, scris în Java, și mă împiedică, dar din anumite motive toată lumea îl laudă. Dar, pentru a lua Microsoft Visual Studio, nu incetineste deloc, dar costa bani si nu se bazeaza pe "scribbling-ul la nivel inferior". În general, progresul progresează rapid, dar nu există nimic de "a merge" cu el.

Inițial Adăugată pe site de Cancer (Сообщение 167773)

În general, progresul progresează rapid, dar nu există nimic de "a merge" cu el.

Da, nu există nici un argument, progresul este încă în desfășurare. Nu înțeleg de ce nu fac aceeași interfață laconică? Și totul altceva. La urma urmei, C32 nu mănâncă gigantul RAM, nu? Nu puteți face mediul mai puțin fericit? Sau se face special pentru ca personalul tehnic să își schimbe de multe ori "caii de fier". ;)

Inițial Adăugată pe site de Romantic (Сообщение 167775)

În ceea ce privește interfața - nu sunt de acord. De ce este inconfortabil?

Sistemul este decent. Există încă laturi cu simulatorul (și nu numai), dar, cred, - dopilyat.

Cine poate spune ce ar putea fi problema? Sistemul XP SP3 a fost actualizat.
1) Pe computer a fost instalat WinAVR, instalați MPLAB X 1.51, creați un nou proiect, faceți clic pe Build (sau Build / Clean), produceți acest lucru:

"CURAT SUCCES (durata totală: 328ms)
face -f nbproject / Makefile-default.mk SUBPROJECTS = .build-conf
face [1]: introducerea directorului "E: /PIC_projects/CAN.X"
make -j 4 -f nbproiect / Makefile-default.mk dist / implicit / producție / CAN.X.production.hex
make [2]: Introducerea directorului `E: /PIC_projects/CAN.X '
process_begin: CreateProcess (NULL, gnumkdir -p build / default / production.) a eșuat.
make [2]: Lăsând directorul `E: /PIC_projects/CAN.X '
face (e = 2): # 65533; # 65533; # 65533; # 65533; # 65533; # 65533; # 65533; # 65533; # 65533; # 65533; # 65533; # 65533; # 65533; # 65533; # 65533; # 65533; # 65533; # 65533; # 65533; # 65533; # 65533; # 65533; # 65533; # 65533; # 65533; # 65533;

face [2]: *** [build / default / production / CAN.o] Eroare 2
make [1]: Lăsând directorul `E: /PIC_projects/CAN.X '
face [1]: *** [.build-conf] Eroare 2
face: *** [.build-impl] Eroare 2

BUILD FAILED (valoare de ieșire 2, timp total: 625ms) "

Ei bine, am decis să eliminăm WinAVR, șterg, apăr pe Build (sau Build / Clean), în general nu există nicio reacție la apăsarea acestor butoane. Apasă Run -> Batch Build Main Project în fereastra de ieșire apare:

"Vă rugăm să așteptați până când fișierele de creare sunt dezinfectate." Procesul de curățare / construire va începe automat după ce fișierele de produse sunt dezinfectate. "

În general, nu înțeleg ce este problema, se pare că WinAVR elimină ceva cu el însuși, iar când îl instalați, MPLAB nu funcționează cu acesta.
Cum să remediați acest lucru, sistemul nu poate fi reinstalat, este necesar să lucrați aici. Eu cer ajutor!

P.S. Am instalat-o pe un laptop cu Win7Pro, MPLAB funcționează, compilează.

face [2]: *** [build / default / production / CAN.o] Eroare 2
make [1]: Lăsând directorul `E: /PIC_projects/CAN.X '
face [1]: *** [.build-conf] Eroare 2
face: *** [.build-impl] Eroare 2

BUILD FAILED (valoare de ieșire 2, timp total: 625ms) "

"Vă rugăm să așteptați până când fișierele de creare sunt dezinfectate." Procesul de curățare / construire va începe automat după ce fișierele de produse sunt dezinfectate. "

P.S. Am instalat-o pe un laptop cu Win7Pro, MPLAB funcționează, compilează.

În general, totul a fost stabilit. WinAVR afectează într-adevăr compilarea în MPLAB X. După dezinstalare, șterge marca care a fost instalată împreună cu ea și referințele din variabila PATH (deci în cmd nu găsiți comanda ca MPLAB).
Dar, GnuWIN32 este instalat cu MPLAB, se află în C: \ Program Files \ Microchip \ MPLABX \ gnuBins \ GnuWin32 \, de fapt adăugăm manual PATH și totul funcționează.

Pagina anterioară

Pagina următoare

Forum micro-chip - mplab ide x

Trimiteți-le prietenilor: